Re: Adding new files to branch puts them in the Attic?

[David L. Martin]

From: "Laine Stump" <address@hidden>
> Files go into the Attic when they don't exist on the trunk. If a file
> is added on a branch, it doesn't exist on the trunk, so the ,v file
> goes in the Attic. When you want to merge your work into the trunk,
> you'll need to add those new files on the trunk, after which the ,v
> file will be moved out of the Attic.
> 

Actually, the merge from branch to trunk will automatically add the
file to the trunk.  It isn't necessary to manually add the file to the
trunk.  The merge will automatically add the file locally.  Upon trunk
commit, the archive will be moved from the Attic to the non-Attic
repository directory.

Beware that if you do manually add a file to the branch and separately
manually add the same file to the trunk, the branch to trunk merge will
result in a conflict.  CVS is confused at this point - it knows that a file was
added on the branch and it wants to add the file on the trunk, but it already
exists.  If the branch is to be merged to the trunk at a future date, it's 
generally
better to add and remove files from the branch only, and let the merge
automatically add or remove these files on the trunk.

To clarify, here's an example.  First, add afile.txt from a branch checkout:

cvs add: scheduling file `afile.txt' for addition on branch `TEST_BRANCH'
cvs add: use 'cvs commit' to add this file permanently

Now, commit it.

cvs commit -m "test log" afile.txt (in directory 
c:\CVSWORK\Homepage_test_branch\test\)
RCS file: C:\My Documents\My 
Programs\cvs_archives/Homepage/test/Attic/afile.txt,v
done
Checking in afile.txt;
C:\My Documents\My Programs\cvs_archives/Homepage/test/Attic/afile.txt,v  <--  
afile.txt
new revision: 1.1.2.1; previous revision: 1.1
done

Note that the archive is created in the Attic.  Also note that two revisions
are actually checked in.  Revision 1.1 is required as the starting revision of 
any CVS
archive, but its state is created as "dead", so it really isn't part of the a 
trunk project (it's
as though it were removed from the trunk).  Revision 1.1.2.1 is the real 
revision on the
branch.  This is basically a 2-for-1 commit where you get two revisions in the 
archive when
you commit a newly-added file from a  branch.

Now, let's switch to a trunk checkout of the same project and merge the branch 
to the
trunk.  (If you a merging multiple times from the branch, you will want to 
using two -j
options, the first specifying the version of the branch last merged to the 
trunk.)

cvs update -P -jTEST_BRANCH (in directory c:\CVSWORK\Homepage\test\)
cvs update: Updating .
U afile.txt
cvs status -v afile.txt (in directory c:\CVSWORK\Homepage\test\)
===================================================================
File: afile.txt         Status: Locally Added

   Working revision: New file!
   Repository revision: 1.1 C:\My Documents\My 
Programs\cvs_archives/Homepage/test/Attic/afile.txt,v
   Sticky Tag:  (none)
   Sticky Date:  (none)
   Sticky Options: (none)

   Existing Tags:
 TEST_BRANCH               (branch: 1.1.2)

Note afile.txt has been automatically added as a result of the merge.

Upon commit, a new (non-dead) trunk revision (1.2) is created, and the archive
is moved out of the Attic:

cvs commit -m "on trunk" afile.txt (in directory c:\CVSWORK\Homepage\test\)
Checking in afile.txt;
C:\My Documents\My Programs\cvs_archives/Homepage/test/afile.txt,v  <--  
afile.txt
new revision: 1.2; previous revision: 1.1
done


We rely on this feature to handle the automatic addition and removal of
files across merges, and CVS performs the task quite well.  Other tools
require manual tracking of the addition and removal of files across branch
merges, which can be a real pain.  The way CVS handles this is a real time
saver...

David Martin