Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000278graphvizBuild/Installpublic2003-09-08 17:152011-04-28 04:02
ReporterStephen M Moraco 
Assigned Toellson 
PlatformOS*-*-N/AOS Version
Summary0000278: Source tar.gz contains CVS directories

Source tarballs should not contain the CVS directories of the developer creating
the tar.gz file. Hint: use 'cvs tag' to label the CVS files then use
'cvs export' from label to get the source tree from which to create the tarball. This
will then NOT contain the CVS subdirectories and will be a good check that
one has correctly labeled the files.

Additional Information

I'm working on trying to get 1.10.0 to build on Debian, but having
build-repeatability problems... More soon. -Stephen

[ellson] Can you expand on why you feel this is important?

The CVS directories aren't all that large, and I thought
it was a rather convenient way of initializing a tree that could be later
updated by cvs.

These are not actually the CVS of a developer, rather they are the
anonymous CVS access of the automatic builds.

[stephen] Now that you ask, I'm having to question myself to find out ;)

Lot's of thoughts come to mind. I not sure if any of them are
all that significant. (Do package style-points count? ;-)

    - CVS directories reflect current state of a checkout from a repository.
      By dropping them on a machine I'm implying that I'm checked out from
      a CVS repository and that is NOT true in this case. As long as these
      files are present, wandering into the tree is mis-leading.

    - It's one of the first checks I do to see if I've got a formally
      released source tree versus somebody's tar-ball of their working

    - In terms of precise release content, you are not releasing the CVS
      directory contents, you are releasing graphviz source. In terms of
      1st bullet, above, you are not releasing the checkout state.

    - In terms of space, they take up space on all of our mirror machines.
      (We mirror source as well as binaries built from the source.)
    - Books on project management w/CVS reflect the steps that I suggested
      ('Hint' in my email.) which result in tar.gz files without CVS directories.

    Note: in addition to alternative CVS commands a command like:

       find . -type d -name CVS -depth -exec rm -rf {} \;

    ...will remove the directories, too, but will smuck your ability to checkout
    over the top, again...

    All-in-all, I'm a long time engineering process/release management guy.
    I coach teams in how to do this and I design release systems. This would
    typically imply that the tar ball is being created too early in the process
    whereas using 'extract' after 'tag' provides a cross-check that the labeling is
    correct. My systems, yes even the daily-automated ones, do the post label
    extraction. And, while, CVS is only one of 5 different CM systems I've used, the
    release process is fairly similar in this aspect across all of them.

    I'm probably worrying all of this for naught as you likely have a robust
    release process. Traditionally, this has been one of the "repackaging" tasks
    I do with the graphviz tar-ball and I finally thought that I'd let you know...
TagsNo tags attached.
[ellson] OK I did this.

It eliminated some crud, so I feel OK with it.

It reduces the size of the tarballs by about 5%.

I used 'find' to remove the CVS directories in the automatic nightly
distributions to avoid having to tag the tree in cvs every ni
STATUS-COMMENTFixed (9 September 2003)
VERSION     1.10.0
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-04-28 04:02 user1 New Issue
2011-04-28 04:02 user1 Assigned To => user695

MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker