[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cancel the last commit

Subject: Re: cancel the last commit
Date: Thu, 20 Jan 2005 16:50:11 +0100
User-agent: 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 "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 ...
address@hidden /var/www/html/ldap/trombintDev]
$ cvs -d :pserver:address@hidden:/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

address@hidden /var/www/html/ldap/trombintDev]
$ 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)

  Existing Tags:
       trombint-2-0-0-patches          (branch: 1.11.2)
       trombint-2-0-0                  (revision: 1.11)
       start                           (revision:
       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:
address@hidden /var/www/html/ldap]
$ mv trombintDev trombintDev.update-A

2) Get the trunk code
address@hidden /var/www/html/ldap]
$ cvs -d :pserver:address@hidden:/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

Your revision tree is perfectly fine, it just has a little wart:

 stuff---stuff---betastuff---rollback---betastuff--- ...
                                +bugfix---bugfix--- ...

Yes this is exactlly what I have .

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".

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]