Re: cancel the last commit

[Pierre Asselin]

Jehan PROCACCIA <address@hidden> wrote:
> [ ... ]
> $ cvs -d :pserver:address@hidden:/var/cvs update -A
> [ ... ]
> 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

It's hard to reconstruct what happened from where I sit, but
you must have been on a branched sandbox *with uncommitted changes*
before you did the "update -A".

An update is always a three-way merge between
    1)  the files in your sandbox
    2)  the files you started from
    3)  the files in the repository at the tip of the
        trunk or branch you are updating to.

If you commit before the update, (1) and (2) are identical, so the
update amounts to replacing (1=2) by (3).  I assumed that you
committed all pending changes to the branch before returning to
the trunk so I'm not sure what happened.

(Of course nontrivial updates are the bread and butter of normal
work on the trunk, where cvs forces you to update *before* committing
your changes.  Conflicts happen in those cases, too, that's normal.
But you were on a branch by yourself, I thought you could commit
everything.  Bah.)

Okay, you can see what kind of damage there is and try to repair
the conflicted files, or ...

> 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

Yes, much easier, but see below.

> 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/

Be careful, the trunk seems to have advanced while all this was
going on.  Make sure that identification.php and cas-header.php
haven't been modified by others, or you will be clobbering their
changes.  I say, was that how the conflicts happened ?  If so you
may be better off cleaning up the conflicts in trombintDev.update-A.

In any case, what you want is a sandbox that
    1)  is on the trunk, and
    2)  has all the new/beta/semibroken changes in it.

> 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 ?

Right.  Just plain "commit", to the trunk.


> I don't really understand this -A option but I tried it ... (see above)

Think of it as a strange way to say "update -r<nothing>".
(Actually it's more like
    update -r<nothing> -D<nodate> -k<defaultkeywords>
)

If view of the confusion, I would double-check that the trunk didn't
lose any work.  Run "cvs log" on the affected files and note which
revisions were committed by you and which ones by others.  Run
"cvs diff" between consecutive revisions and make sure that your
changes don't include rollbacks of other people's changes.

Similarly, on the stable/bufix branch make sure that all the
new/beta stuff is completely gone.  You more or less have to
do that anyway, since having beta stuff would be a "bug"
and on that branch you're fixing bugs.

Good luck.

-- 
pa at panix dot com