You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dan Stromberg <ds...@gmail.com> on 2009/08/05 01:58:46 UTC

svnadmin dump | svnadmin load breaks peg revisions?

We have a quite large subversion repo.  Actually, 6, but I'm mostly
interested in one I cloned to another using svnadmin dump | svnadmin
load.

Things seemed to be going really smoothly, and then I tried to use an
old program I wrote that spiders around in our subversion directories,
svn:externals and comments looking to ferret out what changed from one
tag to another, using light set theory (OK, bags really).

But while the program works well on our old subversion server, on the
new subversion server it runs along for a while and then errors on a
missing peg revision.  I checked the logs for when the directory was
deleted, and found that it was deleted one revision after my program's
trying to get it.  And I svn list'd it at the desired peg revision,
and found that it wasn't there - nor was it there a few revisions
before that according to svn list.  But svn log thinks it existed if I
check its parent directory.

Does svnadmin dump | svnadmin load mess with your peg revisions?

I'm using subversion 1.4.4.

Thanks!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380260

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
On Mon, Aug 10, 2009 at 2:42 PM, Dan Stromberg<ds...@gmail.com> wrote:
> I get the following on our -source- repo (the one I'm copying from
> that has trouble on the target machine).  Does this mean that the
> svnadmin dump is dumping a repo that's bad to begin with?
>
> Odd that my spider would work on the old system but not the new one though.
>
> Anyway, it's as if the directory is there and not there at the same time.
>
> $ svn list -r 15356 "http://localhost/svn/frob/BackupRestore/src/com/frob/"
> svn: warning: cannot set LC_CTYPE locale
> svn: warning: environment variable LANG is en_US.UTF-8
> svn: warning: please check that your locale name is correct
> backuprestore/
> eng2-da_build:~/bin i686-redhat-linux-gnu 16447 - above cmd done 2009
> Mon Aug 10 02:36 PM
>
> $ svn list -r 15356
> "http://localhost/svn/frob/BackupRestore/src/com/frob/backuprestore"
> svn: warning: cannot set LC_CTYPE locale
> svn: warning: environment variable LANG is en_US.UTF-8
> svn: warning: please check that your locale name is correct
> svn: REPORT request failed on
> '/svn/Frob/!svn/bc/56990/BackupRestore/src/com/frob/backuprestore'
> svn: '/svn/Frob/!svn/bc/56990/BackupRestore/src/com/frob/backuprestore'
> path not found
> eng2-da_build:~/bin i686-redhat-linux-gnu 16447 - above cmd done 2009
> Mon Aug 10 02:36 PM
>
> $
>

BTW, the source repo was itself cloned once, from BDB to FSFS.  I
wonder if this is an historical problem left from when we were using
BDB, that is only now biting us?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2382226

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
I get the following on our -source- repo (the one I'm copying from
that has trouble on the target machine).  Does this mean that the
svnadmin dump is dumping a repo that's bad to begin with?

Odd that my spider would work on the old system but not the new one though.

Anyway, it's as if the directory is there and not there at the same time.

$ svn list -r 15356 "http://localhost/svn/frob/BackupRestore/src/com/frob/"
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_US.UTF-8
svn: warning: please check that your locale name is correct
backuprestore/
eng2-da_build:~/bin i686-redhat-linux-gnu 16447 - above cmd done 2009
Mon Aug 10 02:36 PM

$ svn list -r 15356
"http://localhost/svn/frob/BackupRestore/src/com/frob/backuprestore"
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_US.UTF-8
svn: warning: please check that your locale name is correct
svn: REPORT request failed on
'/svn/Frob/!svn/bc/56990/BackupRestore/src/com/frob/backuprestore'
svn: '/svn/Frob/!svn/bc/56990/BackupRestore/src/com/frob/backuprestore'
path not found
eng2-da_build:~/bin i686-redhat-linux-gnu 16447 - above cmd done 2009
Mon Aug 10 02:36 PM

$

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2382219

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Dan Stromberg wrote on Mon, 10 Aug 2009 at 14:15 -0700:
> I got bit by the change in semantics of svn checkout -N, but replacing
> that with --ignore-externals appears to be giving the old -N behavior
> :)  So it wasn't too hard to get past.
> 

-N was deprecated in favour of --depth.

> -=BUT=-, I've still got the bad peg revisions problem.  :(
> 
> I'm beginning to think I should take this to the dev list, but it
> seems like a difficult to replicate issue unless you happen to have a
> copy of our repo, which gets into the issue of whether we can share it
> long enough to get a fix.
> 
> Can anyone on the list confirm that this is a new issue before I bug
> the dev's?  It sounds like they're tired of simple and known issues
> coming up on-list.
> 

Before taking this to dev@, can you show *exactly* what you're doing, 
including the command that gives different results on the two copies of 
the repository, and its outputs in both cases?  (Plus, say how you 
generated the second copy given the first.)

I haven't found that information anywhere upthread (but I haven't read
all of it).  Also, the subject says something about peg revs...

Thanks,

Daniel

> Thanks!
> 
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2382208
> 
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2382247

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
On Fri, Aug 7, 2009 at 2:40 PM, Les Mikesell<le...@gmail.com> wrote:
> Dan Stromberg wrote:
>>
>> Am I correct in thinking that my options are:
>> 1) Plow ahead with the APR and apache (and subversion, with the new
>> APR) compiles
>> 2) Go back to the old subversion, and just live with the potentially
>> corrupted repo that doesn't seem to be preventing modern builds
>> 3) Do a tar | ssh tar despite the word size and slight operating
>> system difference?
>
> Before any of those, I'd look around for pre-built packages of subversion
> and mod_dav_svn for your OS target.  Maybe someone else has done the work
> (that's one of the advantage of running RHEL or CentOS - you can find
> working RPMs for about everything).
>

That's advice to live by, but it seems it just won't work in this
case.  We're stuck with openSUSE 10.3, and...  I suppose there could
be something prebuilt for openSUSE 10.3 somewhere that has recent
apache and subversion and apr, but if there is I sure didn't find it.

I totally agree that when baseline-ing the OS for a product, it's
better to use something with a longer lifetime, but it's too late to
go back and change that now.  We actually were on CentOS for a while,
but one of our partners wanted us to go Novell, and for cost reasons
we went part openSUSE and part SLES.  For this, we pretty much have to
go openSUSE though.

Anyway, I've got things built now - I've upgraded to subversion 1.6.4
and apache 2.2.13.  It was a little more complicated than usual,
because the apache build had problems with both openssl 0.9.8k and
openssl 1.0.0 beta 3 until I got the next version of apache (which
wasn't available when I started) and threw in a cpp symbol I shouldn't
have needed to set manually.  Then apache built against openssl 1.0.0
beta 3.

I got bit by the change in semantics of svn checkout -N, but replacing
that with --ignore-externals appears to be giving the old -N behavior
:)  So it wasn't too hard to get past.

-=BUT=-, I've still got the bad peg revisions problem.  :(

I'm beginning to think I should take this to the dev list, but it
seems like a difficult to replicate issue unless you happen to have a
copy of our repo, which gets into the issue of whether we can share it
long enough to get a fix.

Can anyone on the list confirm that this is a new issue before I bug
the dev's?  It sounds like they're tired of simple and known issues
coming up on-list.

Thanks!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2382208

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Les Mikesell <le...@gmail.com>.
Dan Stromberg wrote:
> 
> Am I correct in thinking that my options are:
> 1) Plow ahead with the APR and apache (and subversion, with the new
> APR) compiles
> 2) Go back to the old subversion, and just live with the potentially
> corrupted repo that doesn't seem to be preventing modern builds
> 3) Do a tar | ssh tar despite the word size and slight operating
> system difference?

Before any of those, I'd look around for pre-built packages of 
subversion and mod_dav_svn for your OS target.  Maybe someone else has 
done the work (that's one of the advantage of running RHEL or CentOS - 
you can find working RPMs for about everything).

-- 
   Les Mikesell
    lesmikesell@gmail.com

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381489

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
On Thu, Aug 6, 2009 at 4:20 PM, Les Mikesell<le...@gmail.com> wrote:
> Dan Stromberg wrote:
>>
>>> Is the subversion server a build host too?
>>
>> Yes.
>
> You might want to consider virtual machines (vmware, virtualbox, etc.) to
> permit different build targets without requiring your own infrastructure to
> always match.
>
>>> Even so, I don't think I'd want
>>> to keep using a 1.4.x.
>>
>> Was 1.4.x kind of unstable or something?
>
> I don't think it was broken - except perhaps for the odd issue you are
> having, but there are improvements in the newer versions that you probably
> want while you are going to the trouble of moving it.
>
> The one thing to watch out for when updating is that newer clients will
> update working copy so you can't access it with older client versions. You
> can still use old clients with a newer server - you just can't access the
> same working copy with new, then old clients.
>
> --
>  Les Mikesell
>   lesmikesell@gmail.com
>

Bad news: the latest subversion is incompatible with the apache plugin
we've been using.

I've built apache before, as well as APR, but I'm not sure I want to
saddle my successor with that.

I built a new mod_dav_svn for the version of apache already on the
system, but that just segfaults.  I'm pretty sure both apache and my
mod_dav_svn were built against the same APR, but subversion's
configure script complained about the APR being too old until I gave
it a path to apxr2.

Am I correct in thinking that my options are:
1) Plow ahead with the APR and apache (and subversion, with the new
APR) compiles
2) Go back to the old subversion, and just live with the potentially
corrupted repo that doesn't seem to be preventing modern builds
3) Do a tar | ssh tar despite the word size and slight operating
system difference?

?

We're fine with a stopgap measure for this.  A long term view is not
necessarily in this case.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381475

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Les Mikesell <le...@gmail.com>.
Dan Stromberg wrote:
> 
>> Is the subversion server a build host too?
> 
> Yes.

You might want to consider virtual machines (vmware, virtualbox, etc.) 
to permit different build targets without requiring your own 
infrastructure to always match.

>> Even so, I don't think I'd want
>> to keep using a 1.4.x.
> 
> Was 1.4.x kind of unstable or something?

I don't think it was broken - except perhaps for the odd issue you are 
having, but there are improvements in the newer versions that you 
probably want while you are going to the trouble of moving it.

The one thing to watch out for when updating is that newer clients will 
update working copy so you can't access it with older client versions. 
You can still use old clients with a newer server - you just can't 
access the same working copy with new, then old clients.

-- 
   Les Mikesell
    lesmikesell@gmail.com

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381118

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 6, 2009, at 17:45, Dan Stromberg wrote:

>> Even so, I don't think I'd want
>> to keep using a 1.4.x.
>
> Was 1.4.x kind of unstable or something?

No, it's just old and no longer supported, as of the 1.6.0 release.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381115

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
On Thu, Aug 6, 2009 at 3:12 PM, Les Mikesell<le...@gmail.com> wrote:
> Dan Stromberg wrote:
>>
>>>> I could make the x86-64 system use a 32 bit subversion if that'd help.
>>>
>>> I don't think I saw an explanation for the problem you are seeing and
>>> this
>>> doesn't sound like the best solution even if it happens to work.
>>
>> I'm on a pretty fixed timeline, but if you believe you can lick
>> whatever bug it is I'm seeing within about 15 calendar days, I suppose
>> I can go for that.
>
> I'm not one of the developers and can't fix anything, but I don't remember
> seeing anyone acknowledge that your situation should exist in the first
> place.  So I'd say the first step should be to try what you did again and
> test peg revision access.
>
>>> Can you try the dump/load into a more recent subversion (preferably the
>>> latest for your OS distro so it will be easy to keep up to date) to see
>>> if
>>> that fixes the peg revision issue?  If it does, that would be a better
>>> base
>>> to do whatever you have to do to back in the subsequent updates.
>>
>> Both OS's appear to come with the same version of subversion, though
>> who knows how many patches the distributors have applied relative to
>> your upstream, and if there are any, there's a pretty good chance they
>> aren't the same patches.
>
> I didn't mean what was shipped with the OS, I meant whatever the current
> update gets you.  But if that's a 1.4.x I'd look for something newer even if
> you have to build it yourself.
>
>> I doubt either OS is the latest from their
>> respective distributors - we need an old OS on our build hosts for
>> compatibility with our product.
>
> Is the subversion server a build host too?

Yes.

> Even so, I don't think I'd want
> to keep using a 1.4.x.

Was 1.4.x kind of unstable or something?

>> I can likely compile the latest
>> subversion on the 32 bit system and copy it over to the 64 bit system
>> for testing, to avoid compiling a 32 bit subversion on a 64 bit
>> system...  It'd probably be easiest to do this under
>> /usr/local/svn/{bin,lib} or similar, copy, and symlink - if there
>> aren't any hardcoded paths in the resulting executables (?).
>
> I'd think you'd want to run a fairly current 64-bit version going forward.
>  You just need to avoid whatever it was that broke your access to peg
> revisions in the process of converting.

Yes, whatever that was.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381111

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Les Mikesell <le...@gmail.com>.
Dan Stromberg wrote:
> 
>>> I could make the x86-64 system use a 32 bit subversion if that'd help.
>> I don't think I saw an explanation for the problem you are seeing and this
>> doesn't sound like the best solution even if it happens to work.
> 
> I'm on a pretty fixed timeline, but if you believe you can lick
> whatever bug it is I'm seeing within about 15 calendar days, I suppose
> I can go for that.

I'm not one of the developers and can't fix anything, but I don't 
remember seeing anyone acknowledge that your situation should exist in 
the first place.  So I'd say the first step should be to try what you 
did again and test peg revision access.

>> Can you try the dump/load into a more recent subversion (preferably the
>> latest for your OS distro so it will be easy to keep up to date) to see if
>> that fixes the peg revision issue?  If it does, that would be a better base
>> to do whatever you have to do to back in the subsequent updates.
> 
> Both OS's appear to come with the same version of subversion, though
> who knows how many patches the distributors have applied relative to
> your upstream, and if there are any, there's a pretty good chance they
> aren't the same patches. 

I didn't mean what was shipped with the OS, I meant whatever the current 
update gets you.  But if that's a 1.4.x I'd look for something newer 
even if you have to build it yourself.

> I doubt either OS is the latest from their
> respective distributors - we need an old OS on our build hosts for
> compatibility with our product. 

Is the subversion server a build host too?  Even so, I don't think I'd 
want to keep using a 1.4.x.

> I can likely compile the latest
> subversion on the 32 bit system and copy it over to the 64 bit system
> for testing, to avoid compiling a 32 bit subversion on a 64 bit
> system...  It'd probably be easiest to do this under
> /usr/local/svn/{bin,lib} or similar, copy, and symlink - if there
> aren't any hardcoded paths in the resulting executables (?).

I'd think you'd want to run a fairly current 64-bit version going 
forward.  You just need to avoid whatever it was that broke your access 
to peg revisions in the process of converting.

-- 
   Les Mikesell
     lesmikesell@gmail.com

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381103

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
I checked for subversion packages for openSUSE 10.3, but found none,
including on Novell's build server.  It's probably just too old an OS
now.

I've gone ahead and built a -64-bit- subversion 1.6.4 in
/usr/local/svn on the -new- server, not the old one.  Advice on
whether to remove the OS's subversion and symlink or just carefully
set $PATH would be valued.  That may or may not have an impact on the
vendor-supplied apache plugin we're using for subversion access.

I'm also checking if anyone internal has anything on the new server
that isn't also on the old server - I requested that people check into
both for a while, but sometimes things happen :)  The idea being that
we don't want to lose any code changes.

Is there any reason to suspect that the openSUSE subversion plugin for
apache wouldn't be compatible with my hand-built subversion?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381104

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
On Thu, Aug 6, 2009 at 1:26 PM, Les Mikesell<le...@gmail.com> wrote:
> Dan Stromberg wrote:
>>
>>>
>>>> That is, is a host to host tar copy of an FSFS repo a good way of
>>>> getting exactly the same stuff on another system?
>>>
>>> Only if they are running the same version of Subversion, the same
>>> operating
>>> system, and have the same type of processor.
>>>
>>>
>>
>> They both have the same release number of subversion installed on them.
>>
>> The old server has CentOS 4.6.  The new server has openSUSE 10.3.
>>
>> The old server is an x86-64 system running an x86 OS.  The new server
>> is an x86-64 system runnnig an x86-64 OS.  So there's a bit of a
>> difference.
>>
>> Is it at all likely that this is close enough that I could just tar | ssh
>> tar?
>>
>> Does an FSFS repo generally have word size and/or endianness details
>> in it?  (FWIW:
>> http://stromberg.dnsalias.org/~strombrg/converting-binary.html)
>>
>> Is svnadmin dump | ssh svnadmin load supposed to just convert to an
>> architecture neutral format and back to a native representation, or is
>> there more to it than that?
>>
>> I could make the x86-64 system use a 32 bit subversion if that'd help.
>
> I don't think I saw an explanation for the problem you are seeing and this
> doesn't sound like the best solution even if it happens to work.

I'm on a pretty fixed timeline, but if you believe you can lick
whatever bug it is I'm seeing within about 15 calendar days, I suppose
I can go for that.

> Can you try the dump/load into a more recent subversion (preferably the
> latest for your OS distro so it will be easy to keep up to date) to see if
> that fixes the peg revision issue?  If it does, that would be a better base
> to do whatever you have to do to back in the subsequent updates.

Both OS's appear to come with the same version of subversion, though
who knows how many patches the distributors have applied relative to
your upstream, and if there are any, there's a pretty good chance they
aren't the same patches.  I doubt either OS is the latest from their
respective distributors - we need an old OS on our build hosts for
compatibility with our product.  I can likely compile the latest
subversion on the 32 bit system and copy it over to the 64 bit system
for testing, to avoid compiling a 32 bit subversion on a 64 bit
system...  It'd probably be easiest to do this under
/usr/local/svn/{bin,lib} or similar, copy, and symlink - if there
aren't any hardcoded paths in the resulting executables (?).

Thanks for being interested in the issue.

> --
>  Les Mikesell
>    lesmikesell@gmail.com
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381080

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Les Mikesell <le...@gmail.com>.
Dan Stromberg wrote:
> 
>>
>>> That is, is a host to host tar copy of an FSFS repo a good way of
>>> getting exactly the same stuff on another system?
>> Only if they are running the same version of Subversion, the same operating
>> system, and have the same type of processor.
>>
>>
> 
> They both have the same release number of subversion installed on them.
> 
> The old server has CentOS 4.6.  The new server has openSUSE 10.3.
> 
> The old server is an x86-64 system running an x86 OS.  The new server
> is an x86-64 system runnnig an x86-64 OS.  So there's a bit of a
> difference.
> 
> Is it at all likely that this is close enough that I could just tar | ssh tar?
> 
> Does an FSFS repo generally have word size and/or endianness details
> in it?  (FWIW: http://stromberg.dnsalias.org/~strombrg/converting-binary.html)
> 
> Is svnadmin dump | ssh svnadmin load supposed to just convert to an
> architecture neutral format and back to a native representation, or is
> there more to it than that?
> 
> I could make the x86-64 system use a 32 bit subversion if that'd help.

I don't think I saw an explanation for the problem you are seeing and 
this doesn't sound like the best solution even if it happens to work.

Can you try the dump/load into a more recent subversion (preferably the 
latest for your OS distro so it will be easy to keep up to date) to see 
if that fixes the peg revision issue?  If it does, that would be a 
better base to do whatever you have to do to back in the subsequent updates.

-- 
   Les Mikesell
     lesmikesell@gmail.com

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381051

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
On Thu, Aug 6, 2009 at 11:24 AM, Ryan
Schmidt<su...@ryandesign.com> wrote:
>
> On Aug 6, 2009, at 13:03, Dan Stromberg wrote:
>
>> That is, is a host to host tar copy of an FSFS repo a good way of
>> getting exactly the same stuff on another system?
>
> Only if they are running the same version of Subversion, the same operating
> system, and have the same type of processor.
>
>

They both have the same release number of subversion installed on them.

The old server has CentOS 4.6.  The new server has openSUSE 10.3.

The old server is an x86-64 system running an x86 OS.  The new server
is an x86-64 system runnnig an x86-64 OS.  So there's a bit of a
difference.

Is it at all likely that this is close enough that I could just tar | ssh tar?

Does an FSFS repo generally have word size and/or endianness details
in it?  (FWIW: http://stromberg.dnsalias.org/~strombrg/converting-binary.html)

Is svnadmin dump | ssh svnadmin load supposed to just convert to an
architecture neutral format and back to a native representation, or is
there more to it than that?

I could make the x86-64 system use a 32 bit subversion if that'd help.

Thanks!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381033

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 6, 2009, at 13:03, Dan Stromberg wrote:

> That is, is a host to host tar copy of an FSFS repo a good way of
> getting exactly the same stuff on another system?

Only if they are running the same version of Subversion, the same  
operating system, and have the same type of processor.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380982

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
OK, I googled up something about renaming a repo, and it seems simple
enough (except for the absolute externals, of course)..

But...  what if I stayed with the same version of subversion, saved my
recent checkins in the form of diffs, toasted my new repos, copied the
repos again using tar | ssh tar instead of svnadmin dump | ssh
svnadmin load, applied the diffs and checked them in?

That is, is a host to host tar copy of an FSFS repo a good way of
getting exactly the same stuff on another system?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380975

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
What's involved in renaming a repository?

It seems like it might be relatively easy to rename the impacted 3
repos, and recreate them with the new version - with the idea in mind
that I could refer back and forth between old and new as needed,
without needing to concern myself much with backups.

On Thu, Aug 6, 2009 at 5:03 AM, <Ul...@elektrobit.com> wrote:
> Ryan Schmidt wrote:
>> On Aug 5, 2009, at 14:47, Dan Stromberg wrote:
>>
>>> Sadly, we already have a bunch of commits against the new server on
>>> 1.4.4.
>>>
>>> Is there a good way of getting just the recent commits from the new
>>> server on 1.4.4, svnadmin dump | svnadmin load, and then putting back
>>> in the recent commits that were on the new server?
>>>
>>> BTW, some of the commits will be on both the old and new servers.
>>
>> svnadmin dump does accept a revision parameter so you can tell it
>> what revisions you want saved into the dumpfile.
>
> Be careful, make lots of backups along the way.
>
> Include --incremental to only dump the changes and --ignore-uuid to keep the UUID intact when loading. The --ignore-uuid should be the default in this case anyway, but it's better to be explicit.
>
> Just my $0.02
>
> Ulli
>
> --
> Ullrich Jans, Application Support, IM
> Phone: +49 9131 7701-6627, mailto:ullrich.jans@elektrobit.com
> Fax: +49 9131 7701-6333, www.elektrobit.com
>
> Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany
> Managing Directors: Otto Fößel, Jarkko Sairanen
> Register Court Fürth HRB 4886
>
>
> ----------------------------------------------------------------
> Please note: This e-mail may contain confidential information
> intended solely for the addressee. If you have received this
> e-mail in error, please do not disclose it to anyone, notify
> the sender promptly, and delete the message from your system.
> Thank you.
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380931

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

RE: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Ul...@elektrobit.com.
Ryan Schmidt wrote:
> On Aug 5, 2009, at 14:47, Dan Stromberg wrote:
> 
>> Sadly, we already have a bunch of commits against the new server on
>> 1.4.4.
>> 
>> Is there a good way of getting just the recent commits from the new
>> server on 1.4.4, svnadmin dump | svnadmin load, and then putting back
>> in the recent commits that were on the new server?
>> 
>> BTW, some of the commits will be on both the old and new servers.
> 
> svnadmin dump does accept a revision parameter so you can tell it
> what revisions you want saved into the dumpfile.

Be careful, make lots of backups along the way.

Include --incremental to only dump the changes and --ignore-uuid to keep the UUID intact when loading. The --ignore-uuid should be the default in this case anyway, but it's better to be explicit. 

Just my $0.02

Ulli

-- 
Ullrich Jans, Application Support, IM
Phone: +49 9131 7701-6627, mailto:ullrich.jans@elektrobit.com 
Fax: +49 9131 7701-6333, www.elektrobit.com

Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany
Managing Directors: Otto Fößel, Jarkko Sairanen
Register Court Fürth HRB 4886 


----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380810

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 5, 2009, at 14:47, Dan Stromberg wrote:

> Sadly, we already have a bunch of commits against the new server on  
> 1.4.4.
>
> Is there a good way of getting just the recent commits from the new
> server on 1.4.4, svnadmin dump | svnadmin load, and then putting back
> in the recent commits that were on the new server?
>
> BTW, some of the commits will be on both the old and new servers.

svnadmin dump does accept a revision parameter so you can tell it  
what revisions you want saved into the dumpfile.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380643

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Dan Stromberg <ds...@gmail.com>.
On Wed, Aug 5, 2009 at 10:40 AM, Ryan
Schmidt<su...@ryandesign.com> wrote:
>
> On Aug 4, 2009, at 20:58, Dan Stromberg wrote:
>
>> We have a quite large subversion repo.  Actually, 6, but I'm mostly
>> interested in one I cloned to another using svnadmin dump | svnadmin
>> load.
>>
>> Things seemed to be going really smoothly, and then I tried to use an
>> old program I wrote that spiders around in our subversion directories,
>> svn:externals and comments looking to ferret out what changed from one
>> tag to another, using light set theory (OK, bags really).
>>
>> But while the program works well on our old subversion server, on the
>> new subversion server it runs along for a while and then errors on a
>> missing peg revision.  I checked the logs for when the directory was
>> deleted, and found that it was deleted one revision after my program's
>> trying to get it.  And I svn list'd it at the desired peg revision,
>> and found that it wasn't there - nor was it there a few revisions
>> before that according to svn list.  But svn log thinks it existed if I
>> check its parent directory.
>>
>> Does svnadmin dump | svnadmin load mess with your peg revisions?
>
> svnadmin dump | svnadmin load should not renumber your revisions, unless you
> used svndumpfilter in between to exclude some items, depending on your
> svndumpfilter settings.
>
>
>> I'm using subversion 1.4.4.
>
> Try the current version, 1.6.3, and try svnadmin verify to make sure it
> thinks the repository is ok.
>
>
>

Sadly, we already have a bunch of commits against the new server on 1.4.4.

Is there a good way of getting just the recent commits from the new
server on 1.4.4, svnadmin dump | svnadmin load, and then putting back
in the recent commits that were on the new server?

BTW, some of the commits will be on both the old and new servers.

Thanks!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380611

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: svnadmin dump | svnadmin load breaks peg revisions?

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 4, 2009, at 20:58, Dan Stromberg wrote:

> We have a quite large subversion repo.  Actually, 6, but I'm mostly
> interested in one I cloned to another using svnadmin dump | svnadmin
> load.
>
> Things seemed to be going really smoothly, and then I tried to use an
> old program I wrote that spiders around in our subversion directories,
> svn:externals and comments looking to ferret out what changed from one
> tag to another, using light set theory (OK, bags really).
>
> But while the program works well on our old subversion server, on the
> new subversion server it runs along for a while and then errors on a
> missing peg revision.  I checked the logs for when the directory was
> deleted, and found that it was deleted one revision after my program's
> trying to get it.  And I svn list'd it at the desired peg revision,
> and found that it wasn't there - nor was it there a few revisions
> before that according to svn list.  But svn log thinks it existed if I
> check its parent directory.
>
> Does svnadmin dump | svnadmin load mess with your peg revisions?

svnadmin dump | svnadmin load should not renumber your revisions,  
unless you used svndumpfilter in between to exclude some items,  
depending on your svndumpfilter settings.


> I'm using subversion 1.4.4.

Try the current version, 1.6.3, and try svnadmin verify to make sure  
it thinks the repository is ok.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380562

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].