[Nico, sorry, you are getting this twice. I forgot to Cc the list
in my original reply.]
On Thu, Mar 20, 2008 at 08:58:27PM +0100, Nico Schellingerhout wrote:
> Stefan Sperling <stsp_at_elego.de> wrote on 03/11/2008 09:28:40 AM:
>
> > Hey Nico,
> >
> > On Tue, Mar 11, 2008 at 01:48:09AM +0100, Nico Schellingerhout
> wrote:
> > > I agree, a move should be treated as a first class citizen:
> for
> > > detecting
> > > conflicts it doesn't matter, but for resolving them
> > > (semi)automatically, it
> > > does.
> >
> > It does matter for detection. Detection would be much, much
> > easier already if we had an update editor callback like
> > move_file(source, target);
> >
> > See the section "TREE CONFLICT DETECTION WITH TRUE RENAMES" in
> >
> http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/detection.txt
> I have read through the section you mentioned, and I am not sure
> what you mean by "true renames".
By "true renames", I essentially mean that functionality you
describe, but implemented in a manner that would make the client
side trivial to implement. The biggest feature would be the
editor function I mentioned, because it would unambiguously
identify moves on the client side, without any logic necessary
in the client to tell moves apart from deletes.
But true renames a dream of course, and I don't really want to
analyze the relationship between true renames and tree conflicts
deeply. Doing so would be a waste of time for now since we already
have a plan mapped out that does not require true renames.
> The real problem appears to be twofold:
> (1) the fact that the client is not given the chance to do this,
> because
> the server omits the copy-from information for adds, leaving the
> client
> in the dark about the user intentions.
> (2) there is no API call "whereis", defined as follows:
> whereis(URL:rev, targetbranchURL:rev), tells you where a file
> identified by URL:rev (on a source branch, for example), can be
> found
> in the targetbranch (note: whereis may return [0:N] URLs because
> of
> possible cloning on the target branch). (Note that this requires
> the ability to search "forward" through the logs efficiently, a
> feature that Subversion does not provide right now AFAIK.)
Indeed, Subversion doesn't do that. As an aside, one of the first things
I did with the Subversion code base was adding support for "copied-to"
properties that simulated just that (all copied files got special properties
stating where they got copied at which revisions). An elego client wanted
the feature badly enough to fund its implementation, however it turns
out it was never used in practice.
> Now, I have no clue about performance impact of these extensions,
> and I
> may be missing ugly consequences, but to me this looks like a path
> worth investigating to not only detect and raise tree conflicts,
> but to
> handle them as well.
>
Performance was quite good once the copied-to pointers were in place,
but handling the insane amount of log output a query like "show me all
logs for copies of a given file for all branches it was ever copied to"
produces was quite a nuisance :)
But I will keep this point in mind and may raise it in future design
discussions when we'll try to get tree-conflicts to the next level.
Right now it's out of scope.
> Of course, for the initial phase of tree conflicts (raising
> conflicts,
> not resolving them), we will have to make do with what Subversion
> provides, and make the best of it.
Yes indeed.
> However, I do not understand
> the
> point in detection.txt that the update editor would have to have
> the
> complete list of all adds with history just to _detect_ tree
> conflicts:
> UC1 and 3 are triggered simply by trying to change or delete an
> absent
> file. That should be enough to flag this as a tree conflict,
> right?
It is enough to flag tree conflicts, but at the moment we are also
flagging double deletes of a file as a tree-conflict, even though
that isn't a tree conflict. The list would be required to tell whether
there is a file that was added with history at all in the update, and
also to relate this file to a file deleted by the update, searching
copy-from info. Only then we could be certain whether a delete was due
to a move operation or not.
Essentially, the rant in detection.txt is the result of me and my
colleague Neels sitting down for a whole evening trying to determine
how we could eliminate all false positives in tree-conflict detection,
and discovering that it is impossible to do so with the current design.
Does the point make sense to you now? Should I update that section
of the file to make its background more clear?
--
Stefan Sperling <stsp_at_elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
- application/pgp-signature attachment: stored
Received on 2008-03-21 13:39:32 CET