[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 22 Jul 2008 14:52:42 +0100

On Mon, 2008-07-21 at 15:27 -0400, Karl Fogel wrote:
> Agreed. But, couple of thoughts:
>
> - No need for "_rev", just call it "svn_wc_kind_t" :-)

Heh. Or whatever.

> - To convert all the existing code to use this sounds like a truly
> stunning amount of work. Am I overestimating? Is this getting
> close to the amount of work required for libsvn_wc_ng?

It's certainly doing something that libsvn_wc_ng wants to do: making the
WC APIs access the various trees that it knows about (working, base,
etc.) more consistently.

I think it's much less effort than the whole wc-ng, though. Only a few
of Subversion's features actually read data (text and props) from an
arbitrary revision that can include "base" and "working". Estimation of
the work needed to "upgrade" these features, listed per svn subcommand:

Significant effort:

  * diff - must communicate this through the diff editor, and there are
different implementations.

  * merge (as source) - if we want this to work, which could be
important for resolving tree conflicts, we would first need to teach it
to read from a local-mod source. After that, would be similar to (one
mode of) diff.

  * copy (as source) - compared to simpler operations below, there is
the complication of storing and retrieving enough metadata to "install"
the copy into the WC.

Pretty simple:

  * cat
  * propget
  * proplist
  * info
  * list
  * mergeinfo
  * export - less important

These could conceivably be upgraded to read from a local-mod source but
don't currently support it so are not in scope:

  * blame

The other "svn" subcommands are not affected.

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.

- 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-22 15:53:02 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.