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

Re: Towards a Shelving MVP

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Tue, 29 Aug 2017 00:06:38 +0000

Julian, regarding your latest mail in this thread:

Daniel Shahaf wrote on Mon, Aug 28, 2017 at 23:27:00 +0000:
> We all seem to be in agreement that we need to store the file contents
> on the shelf's base and the file contents as modified in the shelved
> patch. There are many possible ways to do so: as two full files, or as
> unidiffs, or even as deltas. All these representations are
> interchangeable: any of them can be derived from any other. Which one
> to use is one question.

The fact that all these representations are interchangeable suggests to
me that they all have the same compatibility properties. It shouldn't
matter whether the shelves are stored in a new DB table or in a new
.svn/shelves/ directory; an end user wouldn't be able to tell which of
the two representations we chose.

For example:

> > > Then we would need APIs to:
> > >
> > > * store the result of a WC diff in that format;
> > > * perform a merge, taking input from that storage, into the WC.

The need for new APIs is, pretty much by definition, independent of the
backing storage.

> > > And it would be desirable to have a way to:
> > >
> > > * generate a diff from that storage, to output for review or as a patch.

You mean, if we store shelves as unidiffs in .svn/shelves/, user can
cp(1) them from there? I think it would be good to require users to run
'svn shelf --export-as-unidiff' to get a unidiff: it affords separation
of concerns (between the user-facing functionality and the backing
storage).

> > > I presume a WC format bump would be necessary, making it incompatible
> > > with the current WC format. (Can you see any way around that?)

We need a format bump iff a db query in 1.10 wouldn't DTRT on a wc that
1.11 has touched. I don't see why shelves would introduce any instance
of this — even if they add new DB tables.

(I suppose 1.10 might purge pristines that are only used by shelves, but
then, the worst-case is that somebody who uses 1.10 and 1.11 on the same
working copy will need to re-fetch the pristine from the server.)

> > > * forces us to make 'svn diff' and 'svn patch' feature-complete (and
> > > this I think is highly significant even though it's not within the
> > > stated purpose of shelving).

Storing the patches as deltas and applying them with diff3 will "force
us to make tree-diff3 feature complete", which could also be considered
"highly significant despite not being within the stated scope of
shelving".

Besides, as I said in my previous email, whether we store the shelves as
unidiffs is orthogonal to whether we apply them with 'svn patch'.

>

My overall impression is that diff3 is the so called king's road here:
it's designed for this and it's not all that more expensive than the
alternative.

Cheers,

Daniel

> Then, there is the problem of how to rebase a shelf, i.e., how to apply
> a shelved patch to a different tree than it was composed against. This
> is another question; it is independent of the first one. (This is the
> question to which "apply a unidiff" and "use diff3" were suggested as
> solutions.)
Received on 2017-08-29 02:06:43 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.