[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cancel the last commit
Re: cancel the last commit
Thu, 20 Jan 2005 02:10:33 +0000 (UTC)
tin/1.6.1-20030810 ("Mingulay") (UNIX) (NetBSD/2.0 (i386))
jehan.procaccia <address@hidden> 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 :
> address@hidden /var/www/html/ldap/trombintDev]
> $ cvs tag -c trombint-2-0-0 .
> 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 :
> 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
Your revision tree is perfectly fine, it just has a little wart:
> I read > from online doc
> 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
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