Julian Foad <julianfoad_at_btopenworld.com> writes:
> Did you appreciate it's not just "store here" versus "store there", but
> "store all props in a hash file hidden behind an API" versus "store each
> prop's raw value in a separate visible file and we'll tell you the three
> filenames for each prop of each WC item"?
Yes, or at least I thought I appreciated that. I assume there would
still be an API for getting them, no?
>> > (2) For each property that conflicts, create "old", "theirs" and "mine"
>> > files holding the bare value of that property in the user's WC
>> > directory. (This is where we write the files for text conflicts.)
>>
>> ...ah, I see you were ahead of me :-). Yes, (2), and then there can
>> still be a human-readable .prej file to serve as a readme, explaining
>> what the other files are.
>
> Do you have time to mention why you think (2) is the better option? Is
> it because it's less work to get something that users can see?
I preferred (2) because of its simplicity: the files are out there in
the open, so users can deal with them manually or the user's client can
deal with them via our APIs. And its consistent with what we do with
text conflicts.
> Let me share my goal.
>
> (I'll go and write this up more coherently than I've managed to
> articulate it below.)
>
> TREE CONFLICTS
>
> I've been looking at tree conflicts and how to manage them. We need to
> be able to say to libsvn_wc things like, "Save this copy of this file or
> directory tree somewhere, and give me a reference to it (which I'll call
> 'mine') by which I can access it later." And then the "resolve
> --accept=mine" command needs to say, "Copy the target 'mine' version
> onto its working version." Not, "Copy this property and that property"
> but "copy the whole target including its properties."
>
> The only interest I have in storing properties' old/theirs/mine versions
> is in so far as it helps up build our infrasturcture towards full
> support for tree conflicts.
Aaaaah, okay.
> TEXT CONFLICTS versus PROP CONFLICTS
>
> For text conflicts, we store copies of the file in the user's directory
> and report the file name as a reference. This allows the user to use
> their text editor or other file-based tools, just like they would with
> their working version, but does not allow them to use "svn diff" and the
> like so it's not great.
But note that this limitation is not inherent in storing the files in
the working area. If we were to decide on an 'svn diff' interface to
accessing those files, then they could be accessed in the working area
as easily as in the .svn/ area.
> For property conflicts, I am looking to do something as good or better.
> Saving each separate property value in a file is, I contend, a step in
> the wrong direction.
>
> * Users are not accustomed to interacting with their properties as
> files but rather through the "svn propXXX" commands. We will be exposing
> a way of interacting with property conflicts that I think we will not
> want to support for long.
>
> * The filenames need to be generated: maybe like
> "TARGET.UNIQUEID.mine" or maybe like "TARGET.FUZZYPROPNAME.mine" where
> FUZZYPROPNAME is some fuzzy encoding purged of special characters like
> ":" and restricted in length and uniquified. These filenames will be
> found indirectly through "svn info".
Mmm. That is a problem, yes (and a problem that we don't have with the
working files, by definition).
> "THE ITEM IS IN CONFLICT" versus "THE ITEM HAS SEVERAL CONFLICTS"
>
> It makes sense to resolve all of a file's properties together, and
> together with its text. For example, if the properties do not conflict
> and the text does, and the user chooses to keep "their" version of the
> text, he almost certainly wants to keep "their" version of the
> properties too, not the merged version. (It's also useful to be able to
> look at one property in isolation too, of course.)
>
> In other words, though we presently treat them separately, there is
> logically one conflict on the file, and this conflict involves the text
> and/or one or more properties, and the conflict has one "old" revision
> number (not one for each property and another one for the text), and one
> "their" revision number, and one "mine" version.
Agreed.
> In fact, that is how the "svn resolved" command works - it resolves the
> conflict(s) on the whole file or directory - and that is also what the
> "svn resolve --accept=X" command looks like it should do but in fact it
> quietly ignores properties. (I think "svn resolved --accept=theirs|mine"
> is buggy, accepting the "merged" or "working" version of the properties
> rather than the requested version.)
Also agreed (about how 'svn resolved --accept=X' should behave).
> LONG-TERM GOAL
>
> I want to be able to type "svn diff -r old:mine" to see the entire
> differences in text and props, not "here are the names of some temporary
> files: you have a look at them with your operating system's commands and
> see what you can do with them".
Sure. You can have that no matter where prop conflicts are stored.
> [[[
> $ svn status f
> C f # file 'f' has property conflict(s)
>
> $ svn diff -r old:theirs foo.c
>
> Property changes on: f
> ___________________________________________________________________
> Modified: p
> - v1
> + their-value
> ]]]
>
> STEPS
>
> Now, getting Subversion to that point is a big task, and something we
> can only tackle step by step.
>
> To take a step now, I'd want to store the entire "theirs" set of
> properties in a single "property hash" file, like we do for the "base"
> set of properties and the "working" set (well, we use a sort of diff for
> that, but that's an implementation detail), and such a file is not
> human-readable. It needs an API (and a UI) to access it. Therefore we
> wouldn't put it in the user's directory.
>
> Of course, it only becomes a value-added step to take when we provide
> the API and the UI to access this data, hence this request for comments.
You know, I kind of think the way to go about this is to propose the API
*first*, and then worry about where we're going to store the property
conflicts afterwards. The API is the key thing here.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-15 21:41:05 CEST