subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: Subversion in 2010
Date Tue, 05 Jan 2010 20:47:24 GMT
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

Mime
View raw message