Sounds good to me, on first sight. :)
But then: If a changeset should be able to reference one or more other
changesets, I guess that would mean a change of the format and older
versions of subversion cannot deal with it.
But then again, I have no idea how merge tracking could be done anyway,
most likely it would involve an incompatible change in all cases.
Russ Brown wrote:
> While in the shower this morning I had an idea about how merge tracking
> could be implemented in Subversion which would offer a great deal of
> advantages.
>
> I know that this may have already been considered, but in case it hasn't
> I may as well write it down and post it in case it's useful.
>
> The problems I can see are:
>
> * Merges in SVN are actually just regular changesets, and therefore
> look like any other change. Subversion has no way of knowing whether a
> given changeset was a merge or just a change.
> * Subversion doesn't know what changesets have been merged to a given
> branch from anywhere else.
> * Merging destroys history. If I merge from a branch that many
> developers have worked on to trunk, all of the changes will appear to
> have been made by me. svn blame will have my name written all over it:
> the original authors recieve no credit (or flack) whatsoever.
> * Merges take up space in the repository, even though the deltas
> applied already exist in the repository (on the source branch).
>
> My idea to fix all of these problems is to allow a changeset to
> reference another changeset (or list of changesets).
>
> For example, say you have trunk which represents production and a
> feature branch. Several developers work on the feature branch, making
> several commits.
>
> When performing the merge to trunk, Subversion would examine the
> changesets on the branch and which of those had already been merged from
> that branch, and compile a list of changesets. Subversion then commits a
> changeset containing the new revisions, recording them against the
> trunk. When developers update, it references the changesets in the merge
> changeset and applies the deltas.
>
> svn blame now also knows who wrote every line originally: full history
> is maintained because history is referenced, instead of being copied.
>
> Less space is taken up because you're just referencing changesets
> instead of storing entire deltas again.
>
> Now say there's a merge from trunk to branch. More work is done, and
> again they merge from branch to trunk,
>
> This time, the branch contains a changeset that is a merge from trunk.
> Subversion knows that the changesets referenced by that merge are
> already on the trunk, so it doesn't merge them again.
>
> Thoughts, comments?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 12 10:57:57 2005