Re: [RFC] Property conflicts should save old/theirs/mine versions

On Tue, Jul 22, 2008 at 06:37:38PM +0100, Julian Foad wrote:
> On Tue, 2008-07-22 at 17:56 +0100, Julian Foad wrote:
> > On Tue, 2008-07-22 at 14:52 +0100, Julian Foad wrote:
> > > Now, that's still quite a bit of work and may well be too much to bite
> > > off now (though large chunks of it are temptingly easy). But I think we
> > > need to be considering moves like this, and to something in this
> > > direction sooner or later.
> >
> > For anyone interested, the attached patch contains my work in progress
> > on this.
>
> Of course, I know how unfriendly is a patch without a log message.

Julian,

I read through the whole thread and I totally agree with the
general idea. Being smarter about property conflicts is a
very good thing.

I haven't looked at the patch in detail. But looking at the size
of it, I think you're already close to having enough code to justify
a new branch. If you decided to keep the scope of the branch limited
to the first steps needed towards your long-term goal, and named the
branch accordingly, it might even help preventing the diff from growing
too many new features prematurely. Given the size of what you're aiming
for, I guess anything that helps drawing a line somewhere is probably
a good thing :)

Karl,

even though I totally agree that the API is more important than
where the data ends up being stored, I have a comment on this:

On the tree conflicts branch, we already store conflict data in
the auth area. Here's why:

There may be multiple tree conflicts in a directory, just as there
may be multiple property conflicts on a file or directory.

We want to be able to block commits from tree-conflicted directories
if any of their multiple tree conflicts were not resolved yet.
This is important because the entire point of tree conflict handling
is preventing users from shooting themselves in the foot during
complex merges. Commits that could cause damage without the user
being aware of the potential damage need to be blocked.

Also, we want to be as supportive as we can, and enabling users to
deal with the conflicts one after another is one part of this goal.
With each tree conflict, we associate a ``victim'', i.e. a file or
directory which may be lost or damaged if the conflict is not resolved.
We can then explain each tree conflict (e.g. "The update tried to delete
file foo.c, which you edited") to the user separately.

Users should then be able to tell us "OK, I've resolved the tree
conflict which affects foo.c". We then clear the meta data
corresponding to that tree conflict.

(Note that this is currently not implemented as described.
In the current implementation, running "svn resolved" on a
tree-conflicted directory will clear all tree conflict information.
But the long-term goal is the above behaviour. See issue #3145.)

We first toyed with the idea of storing tree conflict information
in a user-visible file. The file would explain to the user what kinds
of tree conflicts had happened in its containing directory.
There are two possible ways to block commits in such a setup:

1) Don't care about the file's content. Check if the file is still
   present. If it is, disallow commits. If it is not, allow commits.
   This means that we do not have more fine-grained information other
   than "this directory contains one or more tree conflicts".

   Note that this approach is used for text conflicts, by checking
   the presence of .mine, .rX, and .rY and such files.
   It works there because a binary logic is fine in this case:
   The entire file is either text-conflicted or not. We don't
   care about further details, so we don't need more information.

2) Make the file somewhat machine parsable while keeping it
   human-readable, and get per-conflict data from the file.

We (Steve and myself) were inclined to go with 2), but then realised
that any change made by the user to that data could cause us to lose
information about what kind of tree conflicts we had detected during
updates/merges. So we could be tricked into forgetting about some tree
conflicts when the user deleted wrong parts of that file, for example.
We did not like this. Such sensitive data should be in the auth area.
Then it's pretty clear that if users are messing with the data directly,
it's their fault.

So we decided to hide plain tree conflict meta data from users, and put
it in the auth area, and provided an API that translates the meta data
into a human readable form. This is already implemented.
This way, we have the best of both worlds: We control the meta data,
and users are still presented with human-reable information about
tree conflicts.

So Julian's approach to storing property conflicts data in the auth
is consistent with what we have already done on the tree conflicts
branch.

While maintaining consistency between the way text conflicts and
other types of conflicts are handled is certainly desirable, I don't
think it's viable. The way we currently deal with text conflicts is fine.
But it is also much simpler than how we want to deal with tree and property
conflicts. And the way our current trunk code is dealing with either
of those is, well, suboptimal.

Stefan