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
