On Mon, 2008-07-14 at 19:14 -0400, Karl Fogel wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
> > When we get a property conflict, we store a message in "<filename>.prej"
> > that says:
> >
> >> Trying to change property 'p' from 'v1' to 'v2',
> >> but property has been locally changed from 'v1' to 'wcval'.
> >
> > That's OK for a short plain-text value, but is not human-readable for a
> > very long value or a "binary" value, and not machine-parseable if the
> > value contains a single-quote character.
> >
> > Mike and I agree it's totally obvious - "d'uh" - that we should store
> > the "old" and "theirs" and "mine" values in a more rigorous,
> > programmatically-accessible form, as we do for the file text in a file
> > text conflict. This would enable tools built on top of Subversion to
> > offer proper property conflict resolution.
> >
> > I see two solutions (Mike, I only thought of (1) until after talking to
> > you last week, and then I realised you were probably thinking of (2)):
> >
> > (1) Save the item's "old", "theirs" and "mine" properties in the admin
> > area if there is any property conflict on the item.
>
> Why in the admin area? Why not in the working area?
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"?
> > (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?
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.
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.
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".
"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.
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.)
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".
[[[
$ 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.
CONCLUSION
To me, saving individual properties' values in files in the working area
is the clumsy option. It doesn't make much progress towards the above
goals, I think.
This was a "quick fix" idea that came out of discussion about tree
conflicts. From this little excursion into evaluating ways of storing
property-conflict artifacts, it no longer looks like such a quick fix
and it's looking to me now like this might not be the best time to
tackle this. Getting other parts of tree conflicts sorted out is where I
need to spend my time.
Whadd'ya make of that?
- Julian
---------------------------------------------------------------------
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 18:46:06 CEST