[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merge branch vs. commit trunk

From: Jan Hendrik <jan.hendrik_at_bigfoot.com>
Date: 2003-09-24 12:09:43 CEST

Concerning Re: merge branch vs. commit trunk
Jack Repenning wrote on 23 Sep 2003, 8:54, at least in part:

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

Yes, I counted them! ;-) Of course not manually, but by checking
the numbers of two complimentary global changes, only one file
was missing ... Well, web working is different from programming,
changes affecting up to 100 files are not too unsual though I try to
avoid anything larger as much as I can, just for upload time to the
web server.

> 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" ;-)

Yes, I had the weird idea that working on a branch would also
mean that my working copy just holds the changes, too. And did
not realize that somehow the changes first have to be calculated
and second transferred to the repos. And that finally by means of
data streams it does not matter where they go to. But I am too new
to really understand branching and time was too pressuring this
time to try things on a text repos first.

Jan Hendrik
---------------------------------------
Freedom quote:

     The most dangerous man, to any government,
     is the man who is able to think things out for himself,
     without regard to the prevailing superstitions and taboos.
                -- H. L. Mencken, 1919

---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 24 12:08:50 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.