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
Received on Mon Sep 12 17:54:27 2005