Merge tracking idea

[Russ Brown <pi...@gmail.com>]

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?

-- 

Russ.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Merge tracking idea

[Russ Brown <pi...@gmail.com>]

Dirk Schenkewitz wrote:
> 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.
> 

Hmm. I'm wondering if it's possible to have an empty changeset that 
don't change any files as such but just sets a property. If that's the 
case, a property could be used to contain the revision number pointers.

It might not be the most efficient way, but it would work right now. 
You'd then just need to make the server/client understand it so it can 
go off and reference the specified revision numbers when obtaining a 
delta on that changeset.

> 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
> 
> 



-- 

Russ

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Merge tracking idea

[Dirk Schenkewitz <sc...@docomolab-euro.com>]

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