[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 16:50:11 +0100
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
Pierre Asselin wrote:
and when I work on the "new features working set" I want to commit to
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 ...
$ cvs -d :pserver:address@hidden:/var/cvs update -A
indeed this is one of the new files !
cvs update: Updating .
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
$ cvs -d :pserver:address@hidden:/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)
trombint-2-0-0-patches (branch: 1.11.2)
trombint-2-0-0 (revision: 1.11)
start (revision: 126.96.36.199)
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:
$ mv trombintDev trombintDev.update-A
2) Get the trunk code
$ cvs -d :pserver:address@hidden:/var/cvs checkout -r trombint-2-0-0
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
Your revision tree is perfectly fine, it just has a little wart:
Yes this is exactlly what I have .
I read > from online doc
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
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.