You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Hendrik <ja...@bigfoot.com> on 2003/09/23 15:39:43 UTC
merge branch vs. commit trunk
Hi all out there!
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.
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 think that it might be so because of the cheap copy character of
the branch. OTOH the changes must be calculated at some point
anyway and I assume that it is that calculation that was too much
here. So a branch may as well not have made any difference ...
Thanks for any shared experience.
Jan Hendrik
---------------------------------------
Freedom quote:
The right to be let alone is indeed the beginning of all freedom.
-- Supreme Court Justice William O. Douglas
---------------------------------------
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
Re: merge branch vs. commit trunk
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: merge branch vs. commit trunk
Ben Collins-Sussman wrote on 23 Sep 2003, 11:03, at least in part:
> Jack Repenning <jr...@collab.net> writes:
>
> > 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.
>
> Correct. If you had made all your changes on the branch,
> progressively, you still would have had to a single 80 meg merge to
> the trunk. And that merge would have been: apply 80 megs of local
> changes to your 'trunk' working copy (by comparing with the branch),
> then commit. The final commit still would have been 80 megs of data.
I see. I had the idea that the merge would happen on the SVN
server, directly from branch to trunk. Anyway, as I see now, even
progressively committed changes on a branch would not have
worked here as everything I did were more or less global changes,
that is affected large numbers of files at once.
> Now, as to why the commit is grinding to a halt... that's a separate
> topic. Come step into our 'performance/scalability' trouble center,
> take a number and a seat. We have our best men working on it. :-)
Well, as the best men are often also those getting nervous when
being looked at them working I'll better take a three hours walk on
the dyke, even if the first autumn rainstorms hunt me ... ;-)
Jan Hendrik
---------------------------------------
Freedom quote:
Intellect annuls Fate. So far as a man thinks, he is free ...
The revelation of Thought takes man out of servitude into freedom.
-- Ralph Waldo Emerson, Fate
---------------------------------------
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
Re: merge branch vs. commit trunk
Posted by Ben Collins-Sussman <su...@collab.net>.
Jack Repenning <jr...@collab.net> writes:
> 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.
Correct. If you had made all your changes on the branch,
progressively, you still would have had to a single 80 meg merge to
the trunk. And that merge would have been: apply 80 megs of local
changes to your 'trunk' working copy (by comparing with the branch),
then commit. The final commit still would have been 80 megs of data.
Now, as to why the commit is grinding to a halt... that's a separate
topic. Come step into our 'performance/scalability' trouble center,
take a number and a seat. We have our best men working on it. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: merge branch vs. commit trunk
Posted by Jan Hendrik <ja...@bigfoot.com>.
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
Re: merge branch vs. commit trunk
Posted by Jack Repenning <jr...@collab.net>.
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
Re: merge branch vs. commit trunk
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: merge branch vs. commit trunk
John Peacock wrote on 24 Sep 2003, 10:12, at least in part:
> > In terms of diff the changes may well have been significant though
> > they just affected the link column at the start of the pages and the
> > address block at the end.
>
> That's why SSI or some other form of templating is preferred over
> frequent huge global changes. Change the one file that all other
> files include and commit one file.
Quite right. The hoster here, however, asks the double monthly fee
for enabling SSI (together with other things we do not need). OTOH
after some trouble a few years ago they are quite reliable so we are
not very eager here to go for another one who includes the includes
at about the current fees. So I'll continue to limit global replaces
and if I cannot avoid them I'll split up commits ... or try the faster
box next time ...
Jan Hendrik
---------------------------------------
Freedom quote:
The more freedom, the less equality;
the more equality, the less freedom.
-- Max Horkheimer
---------------------------------------
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
Re: merge branch vs. commit trunk
Posted by John Peacock <jp...@rowman.com>.
Jan Hendrik wrote:
> So it looked indeed as the local HDD was quite busy, but no
> activity on the network (the SVN server runs on another machine,
> access via Apache).
Yes, because before the client can talk to the server, it has to generate the
change set locally, hence the need for a better local machine.
>
> In terms of diff the changes may well have been significant though
> they just affected the link column at the start of the pages and the
> address block at the end.
>
That's why SSI or some other form of templating is preferred over frequent huge
global changes. Change the one file that all other files include and commit one
file.
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
Re: merge branch vs. commit trunk
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: merge branch vs. commit trunk
John Peacock wrote on 23 Sep 2003, 11:56, at least in part:
> 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.
Right. I should have said "in the regular working copy, without
switching to a branch or checking out a branch".
> > 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.
So it looked indeed as the local HDD was quite busy, but no
activity on the network (the SVN server runs on another machine,
access via Apache).
But the machine is not so bad. End of 2001 I had a P4 1.6 GHz
machine here, but passed it on after a month: cannot get used to a
mouse lying somewhere on the table, a mile off. I am a keyboard
man, used to the touchpad right under the thumbs. And notebooks
are not so cheap ... Generally I found the P4 was only recognizably
faster in disk access like reading folder contents, else compared to
the P200 the gains were insignificant here. Compiling or diff
calculation may be ifferent.
However, I had thought to copy my working copy to the P4 server
box and do the commit from there. I may do it the next time,
another global change is around the corner: no, I don't like these
global changes, especially not for the upload to the web server, but
since the socialists and greens took over power in Germany in
1998 the speed new laws come out has accelerated. And most
new laws get changed thrice and even more within 12 months.
Someone has calculated that the socialists have created/changed
more acts in the last 4 or 5 years than in the last 20 or 30 years
altogether.
In terms of diff the changes may well have been significant though
they just affected the link column at the start of the pages and the
address block at the end.
Jan Hendrik
---------------------------------------
Freedom quote:
Public servants say, always with the best of intentions,
'What greater service we could render
if only we had a little more money and a little more power.'
But the truth is that outside of its legitimate function,
government does nothing as well or as economically as the private sector.
-- Ronald Reagan, October 27, 1964
---------------------------------------
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
Re: merge branch vs. commit trunk
Posted by John Peacock <jp...@rowman.com>.
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