Jehan PROCACCIA <[EMAIL PROTECTED]> wrote: > [ ... ] > $ cvs -d :pserver:[EMAIL PROTECTED]:/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: > [EMAIL PROTECTED] /var/www/html/ldap] > $ mv trombintDev trombintDev.update-A > 2) Get the trunk code > [EMAIL PROTECTED] /var/www/html/ldap] > $ cvs -d :pserver:[EMAIL PROTECTED]:/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 _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs