Sorry, pressed [Send] too early.
Thanks for the explanations. More below.
Daniel Shahaf wrote on Tue, 11 Jul 2017 22:02 +0000:
> Julian Foad wrote on Tue, 11 Jul 2017 21:53 +0100:
> > Daniel Shahaf wrote:
> > > Julian Foad wrote:
> > >> Checkpointing
> > >>
> > >> Options:
> > >>
> > >> 1. further patch management built on a series of shelved changes
> > >> 2. local commits tightly integrated
> > >> 3. checkpoints are commits in a local repository
> > >
> > > Can you explain these three options in more words? AIUI #1 is
> > > "syntactic sugar to manage a patch series", like quilt(1), but I'm not
> > > sure I understand #2 and #3.
> > 2. What I was thinking there is to rewrite as much of our libs as needed
> > to implement deeply integrated local branching in Svn client. The full
> > extent of what that might entail or look like is unknown.
I don't understand the distinction apparent here between 'checkpointing'
and 'local branching'. Are these two terms not synonymous?
> > 3. To store a series of checkpoints, create a temporary repos inside
> > .svn/ and "relocate" the WC base to it. Then use it for all operations
> > until the user comes to the point they want to commit to the real repo.
I think when wc-ng was invented, the idea was that a 'checkpoint' would
simply be another tree, alongside BASE and WORKING. I suppose this
is option #4.
In general, we have at least five ways of representing a tree: as a
dumpstream, as an editor stream, as a FSFS revision file, as a wc.db
(+ pristine store), as a diff against an empty tree. The 'temporary
repository' could store the changes in any of these forms. I suppose the
question is which representation is best amenable to being replayed and to
resolving conflicts (when rebasing a checkpoint onto a younger start
Received on 2017-07-12 00:39:55 CEST