Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
"Rick Genter" <rgenter at silverlink.com> wrote in message news:mailman.29.1202171111.1277.cvsnt at cvsnt.org... > On 2/4/08 4:03 PM, "Arthur Barrett" <arthur.barrett at march-hare.com> wrote: > >> Eric, >> >>> Is there any way to do a "merge", but to indicate to CVS that >>> what I really >>> want is a fresh copy of a particular version of a file (in >>> this case, the >>> latest HEAD version) in my branch and to not actually try to >>> merge the >>> differences themselves? >> >> No there is not. >> >> The only instances where the 'whole file' should be in conflict is if it >> is a very very small file (diff can't really do much with a 3 line file) >> or if it is a unicode file (there is a bug - we have a patch for >> commercial customers but it is waiting resources to merge it in to >> 2.5.04). >> >> When I need to do a merge/replace what I do is a 'normal' merge then >> take the list of files that were updated and 'copy' them from the >> originating branch/head sandbox over the top of the 'merged' sandbox. >> It's a bit manual - but it is a fairly dangerous thing to do, so I'd >> personally not really be happy with it being automagic. >> >> Alternatively you can use Winmerge tree merge and copy from one >> direction to the other. It is my intention to create a patch for >> Winmerge to create mergepoints properly when this is done - but I've no >> idea how far down my list that task is... > > If you know that the version on the branch is what you want, you can do > the > following: > > 1) Create a sandbox for the trunk : cvs co -P module > -P says to prune empty directories > > 2) To update the trunk so that its contents match that of branch "b": cvs > up > -P -d -jb -jHEAD > > This tells cvs to update the current sandbox merging in all changes from > "b" > to the trunk. Since you are already on the trunk, this effectively > replaces > your files with a copy of what's on branch "b", but your sandbox is still > for the trunk. The -d flag will cause any directories that were created on > "b" since it was branched to be created in the sandbox. The -P will remove > any empty directories once the merge is finished. The result should be > such > that the files/directories in your sandbox is a copy of branch "b", but is > still a trunk sandbox. > > 3) cvs commit -m "Replace trunk with what's on branch b" > This commits the changes to the repository. > > Of course, you can do this for individual files as well: > > cvs up -jb -jHEAD module/path/to/file > > will only update the one file. > > I recommend tagging both branch b and the trunk before you do this so you > can get back to a known state if something goes wrong (like, you meant to > do > one file but do the whole module instead). Perfect! Thanks! Worked like a charm! (with a little manual massaging) Eric