At 5:39 PM +0200 9/23/03, Jan Hendrik wrote:
>
>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). It would not start committing even
>after several hours and I had to stop and part the thing into slices of
>less than 1000 pages each. (I would have preferred to have the
>set of global changes in one revision though, not in five.)
>
>Now my question:
>
>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?
I'm not sure I understand the experiment you ran. Did you really
change 4500 pages? I think that if you change 4500 pages, then the
commit of all those changes is going to be just the same, whether
they go to a branch or trunk. And if the merge ends up changing
those 4500 files again, then you still have to commit the 4500
pages--once again, the same monumental task.
When we say "cheap copy," we mean that the act of making the copy
(branch) is cheap. Once it's made, further work on the branch isn't
any more or less cheap than working on trunk. (Well, some CM systems
are much less efficient working on a branch; they have "expensive
branches" to work on. Subversion's branches are cheaper than that,
but they're only "just the same branches to work on" ;-)
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 23 17:55:18 2003