Pierre Asselin wrote:
and when I work on the "new features working set" I want to commit to "trombint-2-0-0" branch
correction, commit to the trunk. "trombint-2-0-0" is not a branch, it's a (set of) revisions and you can't commit to that. Do a
cvs update -A
and try a "cvs status" again. You'll see that the sticky tag is gone.
You will also notice that any changes you committed to the branch
have been undone. You're back on the trunk.
OK, now it's clean and clear for the stable branche ! now I am on the new/beta feature sandbox (it contains also new files) I do as you recommended below ... [EMAIL PROTECTED] /var/www/html/ldap/trombintDev] $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs update -A ? cas-header.php ... indeed this is one of the new files ! cvs update: Updating . M Changelog.html
OK for that one, but after I get things like that (which I don't like ... :-( )
RCS file: /var/cvs/trombintDev/easyExtract.php,v
retrieving revision 1.3
retrieving revision 1.4
Merging differences between 1.3 and 1.4 into easyExtract.php
easyExtract.php already contains the differences between 1.3 and 1.4
RCS file: /var/cvs/trombintDev/identification.php,v
retrieving revision 1.9
retrieving revision 1.11
Merging differences between 1.9 and 1.11 into identification.php
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in identification.php
C identification.php
[EMAIL PROTECTED] /var/www/html/ldap/trombintDev] $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs status -v identification.php =================================================================== File: identification.php Status: File had conflicts on merge
Working revision: 1.11 Repository revision: 1.11 /var/cvs/trombintDev/identification.php,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)
Existing Tags:
trombint-2-0-0-patches (branch: 1.11.2)
trombint-2-0-0 (revision: 1.11)
start (revision: 1.1.1.1)
jehan (branch: 1.1.1)Do I have to edit each merge-conflicts in every conflict files ? I gets very complicated ....
I was wondering if I could do something simpler:
1) I save the manipulations above: [EMAIL PROTECTED] /var/www/html/ldap] $ mv trombintDev trombintDev.update-A
2) Get the trunk code
[EMAIL PROTECTED] /var/www/html/ldap]
$ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs checkout -r trombint-2-0-0 trombintDev
3) Then copie/replace from my backup of the new/beta feature set every new&modified files to that fresh checkout
$ cp /tmp/trombintDev/identification.php ./trombintDev/
$ cp /tmp/trombintDev/cas-header.php ./trombintDev/
4) After I have put back all the new&modified files into the sanbox (./trombintDev), I will just have to commit ! no need to put -r trombint-2-0-0 it will go there (trunk) anyway ?
Is this solution OK ? for me it looks simpler than correct every merge-conflicts or maybe use what you presented below with update -j XX -j YYbelow, which I must admit I don't really understand :-( .
what do you recommend ?
Thanks a lot for your kind and comprehensive explanations !.
An alternative to flipflopping your sandbox like that is to go to another directory and checkout a brand new sandbox. One sandbox is for the stable line, the other is for the new stuff.
! The problem is that the "new features working set" was checked out before I tagged and branched the repository.
but you rolled it back ! Or so you said at the beginning of the post. You must have, otherwise the "tag -c" would have complained that you had uncommitted changes. The branch really starts at a stable point. Your most difficult task will be to un-rollback the beta stuff on your trunk sandbox (and it probably won't be that difficult).
Your revision tree is perfectly fine, it just has a little wart:
wart | | v stuff---stuff---betastuff---rollback---betastuff--- ... | | +bugfix---bugfix--- ...
Yes this is exactlly what I have .
I read > from online doc https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_16.html#SEC126 section :
A.9.2.2 Creating the branch after editing
[[ hacked sources are present ]]
$ cvs tag -b EXPR1
$ cvs commit -r EXPR1
You don't have that problem. Your hacked sources were already
committed, so it was too late to follow these directions. It
doesn't matter because you rolled them back. Your branchpoint was
a clean, stable baseline. I recommend that you "update -r
trombint-2-0-0-patches" if and only if you want to work on the
*stable* code. Otherwise, "update -A".
I don't really understand this -A option but I tried it ... (see above)
Now about un-rollingback the unstable code you rolled back. You know what the files were, don't you ? the same ones you rolled back. Do them one by one.
cvs update -A # just to be safe cvs status -v file_number_one
The "-v" will give you the low-level revision numbers corresponding to all your tags. Let's say trombint-2-0-0 is revision 1.48 for this file. 1.48 should be identical to 1.46 and 1.47 is the one you rolled back. So,
cvs update -j 1.48 -j 1.47 file_number_one
and you have the unstable file_number_one again, ready to be committed as 1.49. Repeat for the other files,
cvs status -v file_number_two cvs update -j 1.11 -j 1.10 file_number_to # or whatever cvs status -v file_number_three
and so forth. When this is over you will have returned right back to your starting point: broken code in the sandbox. Clean it up if you can and commit. If you can't clean it up yourself go ahead and commit the broken code, tell the other guy to update and make him get the code into shape. Sometimes it's okay to have broken code on the trunk for a short while.
_______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
