jehan.procaccia <[EMAIL PROTECTED]> wrote: > Great I've managed to "rollback" to a stable revision with the above doc. > Now I want to keep that stable revision in production, and create a > branch for new/beta features
or a branch for the *stable* codeline, leaving the new/beta stuff on the trunk. But it's up to you. Personally, I only branch new stuff when it is really speculative and there is an even chance that it will be abandoned. Otherwise, it goes on the wild trunk. > so I tagged that revision : > [EMAIL PROTECTED] /var/www/html/ldap/trombintDev] > $ cvs tag -c trombint-2-0-0 . Excellent. > I want to keep patching if needed that production revision an keep > developping new features, so I created a branch: > $ cvs rtag -b -r trombint-2-0-0 trombint-2-0-0-patches trombintDev Excellent. Your branch is for the stable codeline and the new stuff goes on the trunk. It really is easier that way. If your new/beta is too speculative for the trunk, post again and we'll see how to branch that. > From the CVS doc I can see how to update from any different branch : > https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_5.html#SEC57 > But how do I commit to one branch or an other ? After you "update -r trombint-2-0-0-patches" as the above URL directs you to do, try a "cvs status <somefile>". You'll see that the file (every file, in fact) has a "sticky tag" of "trombint-2-0-0-patches". This stuff causes endless confusion. The tag is stuck to your sandbox; what it means is that when you run a cvs command from that sandbox, there is an implied "-r trombint-2-0-0-patches" as if you had typed it on the command line. In particular, any changes you commit from that sandbox go to the branch and not the trunk because of the implied "-r". Similarly if you update, you get changes that others committed to the branch and nothing from the trunk. > When working on the > production files, I want to commit to branch "trombint-2-0-0-patches" so just commit from the branched sandbox > 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. 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--- ... > 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". 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. -- pa at panix dot com _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
