On Sun, May 9, 2010 at 09:43, Stefan Sperling <stsp_at_elego.de> wrote:
> 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?
As Bert explained, we generate a unique name through appending
numerically-increasing extensions via svn_io_open_uniquely_named.
>> 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?
Nope.
$ svn add foo.c foo.c.left foo.c.1.left
$ # do something to create conflict file: foo.c.2.left
$ svn rm foo.c.1.left
If we scanned for the "left" conflict file, we'd stop at foo.c.1.left
and never find the *real* one: foo.c.2.left
Thus, we have to store the filename that was used.
> 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?
As Bert explained, we need to remove them when the user runs "svn
resolved". He also noted that (somtimes) it is possible manually
resolve a conflict by removing all the conflict files (a potentially
debatable feature).
>> 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:
Yes, we already plan to store the files into the pristine store.
That's why we have the extra checksum columns in ACTUAL_NODE (and the
checksums in the conflict skel).
> svn cat foo.c_at_MINE
> svn cat foo.c_at_THEIRS
> svn cat foo.c_at_OLD
> svn cat foo.c_at_MERGE-LEFT
> svn cat foo.c_at_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 foo.c_at_OLD foo.c_at_THEIRS # diff old->theirs
> svn diff foo.c_at_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.
Dark chocolate, or white?
:-)
Yes... we could add features like this at some point.
On Sun, May 9, 2010 at 14:46, Bert Huijben <bert_at_qqmail.nl> wrote:
>...
> Another option is to still keep them in the separate columns where they are
> now. (Shouldn't be much trouble if we want to store the checksums only in
> their own columns, instead of duplicating them in the skels. But if I
> remember correctly we do duplicate the values)
I'd like to get rid of the columns, and just keep that data in the
skel. There is no need to duplicate the values.
We duplicate the checksums so that a SQL query can determine all
used/referenced checksums (see STMT_SELECT_ANY_PRISTINE_REFERENCE).
Cheers,
-g
Received on 2010-05-09 22:54:45 CEST