Switching between branches: scaling issue

[Folker Schamel <sc...@spinor.com>]

Hello,

When using a branch for developing a particular feature
for some longer time, then typically there are much
more changes merged from trunk to the branch from day
to day than the work itself done on the branch.

Now when doing a merge from trunk to the branch,
every merged file gets a new node in the svn repository,
even if the file will be the same as in trunk, correct?

This means, when switching between trunk and the branch,
the svn server work needed for the switch is proportional
to the (large) number of changes done on trunk
since the branch creation, not proportional to the
(small) number of differences between trunk and branch.

Is this correct?

(If yes, maybe some node hash value map can be used
to identify nodes in the branch which are equal
to the corresponding node in trunk, avoiding
the branch "degeneration"?
This also would reduce the repository size
a lot, because most merge changes in the branch
don't have to be stored separately.)

A side effect I noticed is that when switching,
also files which have been changed since branch creation
but which are equal on the trunk and branch (due to merging)
get a new file time. This can cause ugly recompiles.

Cheers,
Folker

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

Re: Switching between branches: scaling issue

[John Peacock <jp...@rowman.com>]

Folker Schamel wrote:

> When using a branch for developing a particular feature
> for some longer time, then typically there are much
> more changes merged from trunk to the branch from day
> to day than the work itself done on the branch.

I hate to sound like a broken record, but svk does this very well, in that the 
local mirror of trunk can be easily merged with the local branch.  Tthe merge 
back to the trunk is only the changes between the tip of the branch and the tip 
of the trunk (as it should be).

> 
> Now when doing a merge from trunk to the branch,
> every merged file gets a new node in the svn repository,
> even if the file will be the same as in trunk, correct?

Yes, because the branch copy is now changed from being a copy of the original 
trunk file (due to the merge).  Subversion doesn't track merge history (except 
as log entries), so there is no way that it can tell that it should just update 
the pointer on the branch to point at the new version on trunk.

However, I could definitely see the utility of having a new subcommand

	svn update --freshen

which would replace the WC content of a file which was a copy with the newer 
content of the copy source, but only if there were no other local changes.  IOW, 
if the branch node was only a pointer to some other node, --freshen would 
repoint the branch node to the latest revision of the original node.  No, I 
don't know how to program this, and no I don't know how this would work with 
renames of the source node.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

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