Re: merge branch vs. commit trunk

Jan Hendrik wrote:

> Having to do several global changes on our production website I
> was not yet bold enough to do them on a branch. So I did them in
> one of the working copies.

You _always_ make changes in the working copy. The only changes you can make
server side are moves/renames.

>
> However, committing about 4500 pages (80 MB in total) brought
> my machine to its knees (Win2K, P200, 144 MB, CPU usage 4-
> 10%, RAM usage c. 90MB).

That is really a way underpowered machine, IMNSHO. 1.2GHz machines are really
cheap (and the 2GHz are not bad), plus RAM is still reasonable. You also didn't
say how much you changed in the files themselves, since the diff is done on the
local machine.

> Would merging a branch back into trunk generally have been both
> faster and working with all 4.500 files at once, irrespective of the
> machine?

No, because you still would have had to commit the changes to the branch first,
and only then merge with the trunk. I would think that would be even slower
since you changed so many files at once and the repository would have to expand
to have the changed files (no more cheap copies involved). If the server was
very powerful (quad P4 with lots of RAM), the merge might not have been so bad,
but still longer than the commit-only to the trunk.

I doubt any CM system would gracefully handle such a large commit. Just be
thankful that Subversion now lets you break out of a commit without corrupting
the repository.

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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org