On Tue, Jan 05, 2010 at 02:18:25PM -0600, Peter Samuelson wrote:
>
> [Stefan Sperling]
> > Subversion needs to amend its data model to provide copy-to
> > information, to complement the current copy-from information.
> [...]
> > This is easier said than done. It implies repository format changes.
> > We'd need to a way to modify old revisions to store this information
> > because the copy-to data needs to sit at the copy *source*.
>
> Huh ... this part I don't get. Surely the copy-to information would
> live in the same revision where the copy (or rename) actually happens,
> right? That does not require rewriting old data.
Hmmm... food for thought.
In fact if we're just looking at cases where the copy + delete happened in
the same revision, it should even be possible to have the server transmit
copy-to information which it computed dynamically, i.e. we don't need to
store any extra data. Reverting copyfrom relations within a single
revision should be possible, even when merging revision ranges.
> I understand that this does not offer an efficient way to get _all_ the
> places a node has been copied to, but in the case you're talking about,
> we only care about the rename target. If the wc can enforce that both
> sides of a rename be committed at the same time, the copy-to will
> always be in the same revision as the delete.
Revision graphing is another killer application of copy-to information,
which could really only be done if copy-to info was stored in the repository.
> Or, to put it another way, if the copy + delete are in separate
> revisions ... then for tree conflict purposes, we can assume that the
> delete is just a delete.
This could be a nice way to break the copy-to problem down into smaller
pieces, since it would allow us to implement copy-to information
for renames in the client<->server interface before actually storing
it in the repository.
Stefan
Received on 2010-01-05 21:48:11 CET