You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Roland Schwingel <Ro...@onevision.de> on 2003/10/22 08:49:30 UTC
Slow checkin over branches...
Hi ...
The last days I discovered a strange performance problem when checkin over
branches...
So what's the situation
I have a repos with the following layout
/project/head/some/sub/pathes/file
that contains the trunk. I am branching to
/project/<branch>/some/sub/pathes/file
My repos isn't realls small. Trunk and branches each contain about 50000
entries.... Imagine a change to a single file both in trunk and a branch.
I check it in with
svn ci -F <file_with_logtext> --targets <file_with_filestocommit>
<file_with_filestocommit> contains:
/project/head/some/sub/pathes/file
/project/branch1/some/sub/pathes/file
This takes for me about a minute(!) to finish!!!
When I am checkin each file alone each checkin takes about 1 second. Thats
fine.
But why is there that much difference in time???
I have the feeling that when checking in both files at once svn checks the
whole working copy tree for changes, because the harddrive where my working
copy is acts like mad. Wheras with single checkins this is not the case.
Any ideas?
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Slow checkin over branches...
Posted by mark benedetto king <mb...@lowlatency.com>.
On Wed, Oct 22, 2003 at 05:20:03PM +0200, Roland Schwingel wrote:
>
> Thanks,
>
> Roland, hoping for 0.33(?)
>
>
In the meanwhile, you could do something sneaky to commit both
.../wc/trunk/long/path/to/foo
and
.../wc/branches/branchname/long/path/to/foo
I think that this will work:
mkdir ~/commitarea
mv .../wc/trunk/long/path/to ~/commitarea/trunk-to
mv .../wc/branches/branchname/long/path/to ~/commitarea/branch-to
cd ~/commitarea
svn commit
mv ~/commitarea/trunk-to .../wc/trunk/long/path/to
mv ~/commitarea/branch-to .../wc/branches/branchname/long/path/to
Obviously, all this extra work is only useful if your WC is so
big that the juggling time is less than the wc locking time.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Slow checkin over branches...
Posted by Roland Schwingel <Ro...@onevision.de>.
Hi....
cmpilato@localhost.localdomain wrote on 22.10.2003 17:05:04:
> Roland Schwingel <Ro...@onevision.de> writes:
>
> > > I'm guessing this is issue #1245. While you are incorrect in
assuming
> > > that your whole tree is checked for changes, we *do* have a known bug
> > > that would cause practically your whole tree to be *locked* (and
later
> > > unlocked) during the commit process. This can take a long time.
> > Well you are the guru... :-)
> >
> > What I have observed is, that my harddrive works like mad when doing my
> > mentioned action. And the bigger my repos is the longer it takes.
> > (I tried the same with smaller versions). So I was thinking it
> > might run here thru the whole tree, whereas it is not doing that when
> > doing single checkins.
>
> Oh, sure, your harddrive will go to town. To lock a working copy
> means recursively reading the entries file for the whole thing,
> writing lockfiles in all the .svn directories, etc. What you should
> be seeing is that the cost in time is not so much about the size of
> your repository, but the distance between your two paths. They way it
> works is that if you commit two paths by name, (say A/B/C/foo and
> A/B/D/E/bar), the parent of the longest common ancestor of the set of
> the paths (in this case A, the parent of A/B) is locked.
Ah.... I see. That will explain this....
Thanks,
Roland, hoping for 0.33(?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Slow checkin over branches...
Posted by "C. Michael Pilato" <cm...@collab.net>.
Roland Schwingel <Ro...@onevision.de> writes:
> > I'm guessing this is issue #1245. While you are incorrect in assuming
> > that your whole tree is checked for changes, we *do* have a known bug
> > that would cause practically your whole tree to be *locked* (and later
> > unlocked) during the commit process. This can take a long time.
> Well you are the guru... :-)
>
> What I have observed is, that my harddrive works like mad when doing my
> mentioned action. And the bigger my repos is the longer it takes.
> (I tried the same with smaller versions). So I was thinking it
> might run here thru the whole tree, whereas it is not doing that when
> doing single checkins.
Oh, sure, your harddrive will go to town. To lock a working copy
means recursively reading the entries file for the whole thing,
writing lockfiles in all the .svn directories, etc. What you should
be seeing is that the cost in time is not so much about the size of
your repository, but the distance between your two paths. They way it
works is that if you commit two paths by name, (say A/B/C/foo and
A/B/D/E/bar), the parent of the longest common ancestor of the set of
the paths (in this case A, the parent of A/B) is locked.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Slow checkin over branches...
Posted by Roland Schwingel <Ro...@onevision.de>.
Hi...
Thanks for your reply.
cmpilato@localhost.localdomain wrote on 22.10.2003 15:15:23:
> Roland Schwingel <Ro...@onevision.de> writes:
>
> > I have the feeling that when checking in both files at once svn
> > checks the whole working copy tree for changes, because the
> > harddrive where my working copy is acts like mad. Wheras with single
> > checkins this is not the case.
> >
> > Any ideas?
>
> I'm guessing this is issue #1245. While you are incorrect in assuming
> that your whole tree is checked for changes, we *do* have a known bug
> that would cause practically your whole tree to be *locked* (and later
> unlocked) during the commit process. This can take a long time.
Well you are the guru... :-)
What I have observed is, that my harddrive works like mad when doing my
mentioned action. And the bigger my repos is the longer it takes.
(I tried the same with smaller versions). So I was thinking it
might run here thru the whole tree, whereas it is not doing that when
doing single checkins.
Just wanted to post my observation (by hoping it might get on a list
of items to fix sometime). At present I am checking in splited what
means I have for the same change 2 (or more) commits, would be more
nicer to have them in which makes more sense if you look back
later in some years.
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Slow checkin over branches...
Posted by "C. Michael Pilato" <cm...@collab.net>.
Roland Schwingel <Ro...@onevision.de> writes:
> I have the feeling that when checking in both files at once svn
> checks the whole working copy tree for changes, because the
> harddrive where my working copy is acts like mad. Wheras with single
> checkins this is not the case.
>
> Any ideas?
I'm guessing this is issue #1245. While you are incorrect in assuming
that your whole tree is checked for changes, we *do* have a known bug
that would cause practically your whole tree to be *locked* (and later
unlocked) during the commit process. This can take a long time.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org