Am 27.03.10 01:14, schrieb J Decker: > mtn update --move-conflicting-paths works pretty good under windows > when I have updates that drop directories that are not empty. Thank > you greatly for providing a method to work around this. > > At the end of the update, the files and directories that caused the > paths to not be empty are left in _MTN/resolutions. > > After a very long update, it might be nice to know that there are > folders left in _MTN/resolutions, I think this might be logged when > the command starts, but if you have a very long list of drops, there > is no notification at the end.
Since --move-conflicting-paths has to be given explicitely, I think this is actually not needed. If you add this option you _know_ that _MTN/resolutions will contain the paths which have been moved there in order to complete the update successfully, so a simple ls -l _MTN/resolutions should be enough. > Bug? :The documentation from mtn update --help says "move conflicting, > unversioned paths into _MTN/conflicts before..." but there's nothing > in _MTN/conflicts... are conflicts then moved to resolutions? No, I think this is just a documentation bug. > and, I dunno, I'm kinda thinking that what's left over should be moved > back into the workspace after the drops are complete; though I did say > to drop the directory (and all tracked content)... ya, if I was > working in a sub-tree of a parent that was deleted, untracked work > should probably be saved in the workspace... but then, a stronger > notice should maybe apply to indicate that conflicting content from > the drop is left in _MTN/revisions, and you might want to move it out. I've implemented this functionality once to allow clean workspace updates without the hassle of being stopped because of unversioned paths and to my knowledge only conflicting unversioned paths are moved. That means of course that it should be almost impossible to move conflicting paths back to the workspace after the update just because, well, they conflict with versioned paths. Typical problems here are: * a unversioned file and a versioned directory with the same name existed (or vice versa) * unversioned files in a removed directory existed I don't see a way to "resolve" these automatically after the update was completed successfully. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
