Re: cancel the last commit

[Jehan PROCACCIA]

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