You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mark Bainter <ma...@webtech.dresser.com> on 2003/10/16 17:10:50 UTC
.30 svnadmin dump fails with v1 repos?
I fell behind a bit on updating my subversion install and
finally got some time to update the other day and jumped to
.30. I went to do some work with it today and got the v2
expected error.
I found the repo upgrade notes and started the dump/reload
but got this:
% svnadmin dump svn-old/ > svn_repo_dump
svn: Unsupported repository version
svn: Expected version '2' of repository; found version '1'
...Do I need to downgrade to .29 to be able to do the
repository upgrade?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: .30 svnadmin dump fails with v1 repos?
Posted by Ben Collins-Sussman <su...@collab.net>.
Mark Bainter <ma...@webtech.dresser.com> writes:
> Going forward, any thoughts on maybe keeping a staticly compiled binary
> around of svnadmin so that those of us that don't upgrade every time
> there's a release don't have to make waypoint upgrades just to get
> to the latest version?
The 0.27 tarball is still up on http://svn.collab.net/tarballs/. It's
not going anywhere.
And so far, no volunteers have ever posted *any* precompiled binaries,
static or not, for any release, other than some win32 ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CRLF -> LF on checkout
Posted by Barry Scott <ba...@barrys-emacs.org>.
What you cannot do it tell SVN what the default line ending is for
your checkout. Not a problem usually, expect where you checkout
on win32 into a samba share for use on Unix.
BArry
At 16-10-2003 20:13, C. Michael Pilato wrote:
>Christopher Baus <ch...@yahoo.com> writes:
>
> > I remember reading on the list that you can convert
> > between Unix and DOS new lines during checkout. I've
> > tried to find this in the documentation and have
> > unfortunately failed.
>
>This is not *strictly* accurate, but you *can* specify what
>line-ending style you would like a given file to have when checked out
>by using the svn:eol-style property (see 'svn help propset').
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
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
Slow checkin over branches...
Posted by Roland Schwingel <Ro...@onevision.de>.
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: CRLF -> LF on checkout
Posted by "C. Michael Pilato" <cm...@collab.net>.
Christopher Baus <ch...@yahoo.com> writes:
> I remember reading on the list that you can convert
> between Unix and DOS new lines during checkout. I've
> tried to find this in the documentation and have
> unfortunately failed.
This is not *strictly* accurate, but you *can* specify what
line-ending style you would like a given file to have when checked out
by using the svn:eol-style property (see 'svn help propset').
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
CRLF -> LF on checkout
Posted by Christopher Baus <ch...@yahoo.com>.
I remember reading on the list that you can convert
between Unix and DOS new lines during checkout. I've
tried to find this in the documentation and have
unfortunately failed.
Could someone point me in the right direction?
Thanks,
Christopher
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
svn del dir --force fails delete symoblic links
Posted by Christopher Baus <ch...@yahoo.com>.
I'm not sure if this a known bug but the command in
the subject fails to delete symbolic links on Linux.
Here's that command again..
svn del dir --force
~christopher
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: .30 svnadmin dump fails with v1 repos?
Posted by Mark Bainter <ma...@webtech.dresser.com>.
C. Michael Pilato [cmpilato@collab.net] wrote:
> Mark Bainter <ma...@webtech.dresser.com> writes:
>
> > I fell behind a bit on updating my subversion install and
> > finally got some time to update the other day and jumped to
> > .30. I went to do some work with it today and got the v2
> > expected error.
> >
> > I found the repo upgrade notes and started the dump/reload
> > but got this:
> >
> > % svnadmin dump svn-old/ > svn_repo_dump
> > svn: Unsupported repository version
> > svn: Expected version '2' of repository; found version '1'
> >
> > ...Do I need to downgrade to .29 to be able to do the
> > repository upgrade?
>
> You need to downgrade to 0.27 (that last release before the repository
> schema change, according to the CHANGES file).
>
Thanks. I'll do that.
Going forward, any thoughts on maybe keeping a staticly compiled binary
around of svnadmin so that those of us that don't upgrade every time
there's a release don't have to make waypoint upgrades just to get
to the latest version?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: .30 svnadmin dump fails with v1 repos?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Bainter <ma...@webtech.dresser.com> writes:
> I fell behind a bit on updating my subversion install and
> finally got some time to update the other day and jumped to
> .30. I went to do some work with it today and got the v2
> expected error.
>
> I found the repo upgrade notes and started the dump/reload
> but got this:
>
> % svnadmin dump svn-old/ > svn_repo_dump
> svn: Unsupported repository version
> svn: Expected version '2' of repository; found version '1'
>
> ...Do I need to downgrade to .29 to be able to do the
> repository upgrade?
You need to downgrade to 0.27 (that last release before the repository
schema change, according to the CHANGES file).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org