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.
Bo Berglund wrote: > There is, however, a slight problem here: > If a developer has a number of changes in his files that he has > tested and is now ready to commit them he must first do a cvs update > to make sure his files are revision wise at the top of the tree. Personally I only perform that step when I actually get the "Up-to-date check failed" message but then we're a really small team with strong distribution of responsibilities and few overlaps and the possibility of even more changes being committed while I resolve this situation is rather minimal. I could see that this procedure is not feasible when there is a constantly high potential for other people committing changes to your files while you're working on them. > It would be nice to have a possibility to undo a cvs update thus > bringing back the file states to what they were in just before the > update when they contained only the developer's own edits on top of > the revision he started out with. It would not be a great tool, but it > would make it possible for the developer to recreate his files and > revision state so he can at least create a branch at that point and > store his edits into that branch.... > > Maybe there is just such a function available that makes use of the > #-marked files that get created during updates??? That should be a relatively easy task for a WinCvs macro. Something like "Undo merge"... It would: - scan the selection for files with the "Result of merge" comment, - then locate the latest .#<filename>.<revision> instances for each of those files (striking again from the list those files for which no backup exists), - update -Cr each of those files back to the revision identified in the previous step (just to update the ./CVS/Entries* files), - overwrite the files with the merge backups This would make the revisions sticky but I don't think that should be a problem as you couldn't simply commit them anyway. You would still be able to diff them to HEAD and/or create a branch from that point. It also has the added benefit of letting you update without reproducing the unwanted merge. Alternatively I could let the macro manipulate the revision in ./CVS/Entries directly without making it sticky but I'd rather like to avoid that. Do you think that would be useful? Cheers, -- Oliver ---- ------------------ JID: ogiesen at jabber.org ICQ: 18777742 (http://wwp.icq.com/18777742)