On Sat, May 08, 2010 at 11:15:31PM -0400, Greg Stein wrote: > Hey all, > > In wc-1, we record filenames where merge sources are stored, and where > property rejects are written. These are: > > entry->conflict_wrk, ->conflict_old, ->conflict_new, and ->prejfile > > These file names do not appear to have any corresponding values in the > proposed skels detailed in notes/wc-ng/conflict-storage. > > We cannot simply derive the filenames because there may be versioned > (or unversioned) content with the same names.
That problem must also exists in wc-1. What does wc-1 do if the files already exist? > We don't apply/make rules on file naming, so the code works on finding > unique names along certain understandable patterns. But I believe we > need to record *what* name was chosen. Well, I've been under the impression that the names are currently 100% predictable. Is that not the case? Assuming the names are predictable, I don't see a need to record the names, so can you explain what you think would break by not recording them? What problem does it really cause for us, or for users? > I'm unsure of how to model this. Any ideas? Not sure if this is a good answer to your question, but here's an idea that we've been tossing around for a while ("we" includes Julian and myself, and maybe others): As well as dumping tempfiles into the working copy, store copies in the pristine store and make them available with keywords like: svn cat fo...@mine svn cat fo...@theirs svn cat fo...@old svn cat fo...@merge-left svn cat fo...@merge-right Then people can re-create the tempfiles at will, and give them whatever names they like. Bonus points if diffing against BASE or any other stored version of the file is possible. svn diff fo...@old fo...@theirs # diff old->theirs svn diff fo...@merge-left # diff base->merge-left And if we could later extend this to entire directory trees, that would be a purple-sky dream world with rivers of honey and marshmallow trees with chocolate leaves. Stefan