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
