Re: Performance Decrease After Moving Working Copy to Another Machine

[Johan Corveleyn]

On Wed, Jun 15, 2016 at 11:36 PM, Brandon Eusebio  wrote:
> Hello,
>
>
>
> I am trying to move/copy a Subversion (version 1.8.10) working copy from one
> linux machine to another. From researching similar questions/answers, this
> seems possible by simply moving the entire folder (along with the .svn
> subdirectory). I have implemented a solution that performs this copy using
> tar.
>
>
>
> On source machine:
>
> `tar -cpz -f checkout_directory.tar.gz checkout_directory`
>
>
>
> On destination machine (after copy of the tarball):
>
> `tar -xpz -f checkout_directory.tar.gz`
>
>
>
> This achieves the goal of moving the working copy to the destination
> machine; however the performance of svn operations becomes drastically
> slower. For example, a `svn status` on the original machine takes < 1
> minute, but takes ~1 hour on the destination machine. The entire folder is
> ~50GB, but these timings include clearing out the linux buffers/caches and
> similar hardware/load on each machine.
>
>
>
> I can mitigate the performance hit by doing an `svn cleanup` on the
> destination machine, but this operation also takes ~1 hour. I suspect this
> updates the change times that Subversion uses to determine whether or not
> local changes have been made
> (http://svn.haxx.se/users/archive-2003-11/0595.shtml).
>

Yes, for the working copy to work optimally, the mtimes (last
modification time) of the files need to correspond exactly to the
corresponding values in the svn metadata (stored in .svn/wc.db, an
sqlite database). Running 'svn cleanup' will fix this, because it
corrects the metadata in wc.db to note the correct mtimes.

I'm not sure if your tar commands precisely preserve the mtimes of the
files (googling around for tar and mtime brings up several discussions
where "it should, but sometimes it doesn't"). And with precisely, I
mean "up to the nanosecond, exactly the same timestamp as on the
original file". Also: what sometimes happens is that there is a
difference in filesystems between source and target of the copy, so
they might have different timestamp granularity on the filesystem
level, leading to slightly different timestamps.

I would suggest you try to verify the timestamps for some files in the
source and target working copies, and their corresponding values in
wc.db:

1) Run "ls" with some option to display precise timestamps (on Solaris
you get "full-iso" time-style by running "ls -E", don't know the exact
equivalent for linux). Check this on source and target. If they are
different then there is your problem.

2) To double check, you can also see what the value in wc.db is, by
running a query with sqlite3 like this:

sqlite3 -header -column wc.db "select local_relpath, last_mod_time
from nodes where local_relpath='path/to/file'"

You'll probably have to convert the value you get there (it will be in
milliseconds or microseconds "since epoch"), for instance use this:
http://currentmillis.com/

HTH,
-- 
Johan

Re: Performance Decrease After Moving Working Copy to Another Machine

[Andreas Stieger]

Hi,

Brandon Eusebio wrote:
> I am trying to move/copy a Subversion (version 1.8.10) working copy 
> from one linux machine to another.
[...]
> however the performance of svn operations becomes drastically slower.

Are the machines software identical w.r.t. svn and it's dependencies?
In particular, can you give the output svn --version -v and the linked SQLite 
version?

rsync -t?

Andreas

Invalid character in hex checksum?

[Sander Smeenk]

Hi,

I'm having a challenge with subversion and old(er) repositories.
I'm currently running svn 1.9.3 (r1718519) but the repositories were
created back in june 2006, i'm not sure what the svn version was back
then.

I had an old local checkout which i had to 'upgrade':
| % svn up
| svn: E155036: Please see the 'svn upgrade' command
| svn: E155036: The working copy at '/home/sanders/svn/foo'
| is too old (format 10) to work with client version '1.9.3 (r1718519)'
| (expects format 31). You need to upgrade the working copy first.

So i did:
| % svn upgrade
| Upgraded '.'
| Upgraded 'debian'
| Upgraded 'debian/source'

But the result is that every action afer that results in an obscure error:
| % svn up
| Updating '.':
| svn: E125012: Invalid character in hex checksum

Trying to do a new checkout of the old repository also results in this error 
message:
| % svn co file:///svnroot/foo newcheckout
| svn: E125012: Invalid character in hex checksum

The issue 'thus' lies in the repository itself. Not the checkout.

Posts found on Google suggested that doing an 'svnadmin dump' with an
older version of svn, and 'svnadmin load'-ing that on a new svn system,
essentially recreating the repostory from scratch, helps recover from
this situation which is indeed true.
This is all nice if a repo has a few commits but, as one might
imagine, a repo from 2006 has a gazillion of commits. The one i'm
testing with is really small, but i also have a repo that's 28GB on
disk and i don't really feel like dumping and loading that.

So i tried 'svnadmin recover' with the 1.9.3 client on the old repo:
| % svnadmin recover /svnroot/foo
| Repository lock acquired.
| Please wait; recovering the repository may take some time...
| svnadmin: E24: Could not convert '/
| 
| 
| 17' into a number

No dice.

Then tried 'svnadmin upgrade' with the 1.9.3 client on the old repo:
| % svnadmin upgrade /svnroot/foo
| Repository lock acquired.
| Please wait; upgrading the repository may take some time...
| Bumped repository format to 7
|
| Upgrade completed.

Looks good. Tried a new checkout w/ 1.9.3:
| % svn co file:///svnroot/foo herp   
| svn: E170013: Unable to connect to a repository at URL 'file:///svnroot/foo'
| svn: E180001: Unable to open repository 'file:///svnroot/foo'
| svn: E125006: '/svnroot/foo/db/format' specifies logical addressing for a 
non-sharded repository

No dice.

[ .. Some time passes while i google this 'logical addressing' thing .. ]

Someone[1] hacked 'addressing logical' from the /svnroot/foo/db/format file.
As did i. Things are now working.

Pfoo. I'd have to test this extensively with the 28GB repository.

I fear that running 'svnadmin upgrade' on the repositories will break
compatibiltiy with older (though not 2006-old) SVN-clients and i don't
like messing with 'addressing logical' in repository files as i have NO
idea what this means at all.

Can anyone explain to me what is going on?

Thx,
-Sander.

[1] https://cygwin.com/ml/cygwin/2015-09/msg00361.html
-- 
| I wish i was a glow worm, a glow worm's never glum.
| How can you be unhappy when the sun shines out your bum!
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

Re: Invalid character in hex checksum?

[Stefan Sperling]

On Thu, Jun 16, 2016 at 10:51:27AM +0200, Sander Smeenk wrote:
> Trying to do a new checkout of the old repository also results in this error 
> message:
> | % svn co file:///svnroot/foo newcheckout
> | svn: E125012: Invalid character in hex checksum
> 
> The issue 'thus' lies in the repository itself. Not the checkout.
> 
> Posts found on Google suggested that doing an 'svnadmin dump' with an
> older version of svn, and 'svnadmin load'-ing that on a new svn system,
> essentially recreating the repostory from scratch, helps recover from
> this situation which is indeed true.

Then this is the upgrade path you should follow.

> This is all nice if a repo has a few commits but, as one might
> imagine, a repo from 2006 has a gazillion of commits. The one i'm
> testing with is really small, but i also have a repo that's 28GB on
> disk and i don't really feel like dumping and loading that.

'svnadmin dump/load' is supposed to be faster in 1.9 than it was before.
But I have no first-hand experience with that.

> I fear that running 'svnadmin upgrade' on the repositories will break
> compatibiltiy with older (though not 2006-old) SVN-clients

No, it won't. As long as older clients access the repository over the
network (i.e. not via file:// URLs) there will be no compatibility problem.

> and i don't
> like messing with 'addressing logical' in repository files as i have NO
> idea what this means at all.

See the table here:
http://subversion.apache.org/docs/release-notes/1.9.html#fsfs-improvements
Logical addressing the what the 'Fast access to cold data on disk' row
is all about.

It looks like there could be a bug in the repository upgrade code.
Your repository got new repository format semantics applied to it when
it shouldn't have. Logical addressing only makes sense with packed
repositories which were created as format 7.

Can you run 'svnadmin info' (exists as of 1.9) on the old (non-upgraded)
repository and show the output? That will give us details about its format.

In any case, I would stick with dump/load in your situation instead of
'svnadmin upgrade' which is obviously not working right in your case.
You should rather let the computer spend some time dealing with the dump
and load process, instead of spending your own time working around problems
and not even knowing if the result of your workarounds will be OK.

Re: Invalid character in hex checksum?

[Sander Smeenk]

Quoting Stefan Sperling (s...@elego.de):

> > I fear that running 'svnadmin upgrade' on the repositories will break
> > compatibiltiy with older (though not 2006-old) SVN-clients
> No, it won't. As long as older clients access the repository over the
> network (i.e. not via file:// URLs) there will be no compatibility problem.

I will have to read up on the changes and incompatibilties it
introduces. Some of my systems use direct file:// access (although afaik
just for checkouts, no commits). So this *might* still be an issue.


> http://subversion.apache.org/docs/release-notes/1.9.html#fsfs-improvements
> Logical addressing the what the 'Fast access to cold data on disk' row
> is all about.

Thanks.


> Can you run 'svnadmin info' (exists as of 1.9) on the old (non-upgraded)
> repository and show the output? That will give us details about its format.

The output is as follows:

| % svnadmin info foo
| Path: foo
| UUID: d7ac1088-da18-0410-849e-888fbd42cb43
| Repository Format: 3
| Compatible With Version: 1.1.0
| Filesystem Type: fsfs
| Filesystem Format: 1
| FSFS Sharded: no
| FSFS Logical Addressing: yes
| Configuration File: foo/db/fsfs.conf

Indeed it lists Logical Addressing 'yes'. 


> In any case, I would stick with dump/load in your situation instead of
> 'svnadmin upgrade' which is obviously not working right in your case.

As i understand, dump/load-ing also activates the new features like the
'pack' stuff. I have to read in to that and find out what this means for
o(l|th)er clients.

I use svn to commit changes but am not very experienced with the deeper
internals of svn's workings. ;)


> You should rather let the computer spend some time dealing with the dump
> and load process, instead of spending your own time working around problems
> and not even knowing if the result of your workarounds will be OK.

Will have to plan a maintenance window then. 
Gah. :)


Thanks for your prompt reply!
-Sndr.
-- 
| Showering in clothes shows you're crazy. Showering nude shows your nuts.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

FSFS Format 1 with logical addressing ?!? (was: Re: Invalid character in hex checksum?)

[Stefan Sperling]

On Thu, Jun 16, 2016 at 11:49:32AM +0200, Sander Smeenk wrote:
> Quoting Stefan Sperling (s...@elego.de):
> > Can you run 'svnadmin info' (exists as of 1.9) on the old (non-upgraded)
> > repository and show the output? That will give us details about its format.
> 
> The output is as follows:
> 
> | % svnadmin info foo
> | Path: foo
> | UUID: d7ac1088-da18-0410-849e-888fbd42cb43
> | Repository Format: 3
> | Compatible With Version: 1.1.0
> | Filesystem Type: fsfs
> | Filesystem Format: 1
> | FSFS Sharded: no
> | FSFS Logical Addressing: yes
> | Configuration File: foo/db/fsfs.conf
> 
> Indeed it lists Logical Addressing 'yes'. 

Has this repository been touched by 1.9 'svnadmin upgrade'?
Or is this a pristine format 1 repository which you created with
Subversion 1.1.0 and never upgraded since?

In either case, I believe the above is not valid. Logical addressing should
only be enabled for "Filesystem format: 7" repositories, as far as I know.

Stefan2 (now in Cc), any ideas what could be going wrong here?

Re: Invalid character in hex checksum?

[Evgeny Kotkov]

Sander Smeenk  writes:

>> Can you run 'svnadmin info' (exists as of 1.9) on the old (non-upgraded)
>> repository and show the output? That will give us details about its format.
>
> The output is as follows:
>
> | % svnadmin info foo
> | Path: foo
> | UUID: d7ac1088-da18-0410-849e-888fbd42cb43
> | Repository Format: 3
> | Compatible With Version: 1.1.0
> | Filesystem Type: fsfs
> | Filesystem Format: 1
> | FSFS Sharded: no
> | FSFS Logical Addressing: yes
> | Configuration File: foo/db/fsfs.conf
>
> Indeed it lists Logical Addressing 'yes'.

This is a bug that has been fixed recently.  The fix will be available in
the next patch release of Subversion 1.9:

https://svn.apache.org/r1720015
https://svn.apache.org/r1743454


Regards,
Evgeny Kotkov

Re: Invalid character in hex checksum?

[Stefan Sperling]

On Thu, Jun 16, 2016 at 01:08:37PM +0300, Evgeny Kotkov wrote:
> Sander Smeenk  writes:
> 
> >> Can you run 'svnadmin info' (exists as of 1.9) on the old (non-upgraded)
> >> repository and show the output? That will give us details about its format.
> >
> > The output is as follows:
> >
> > | % svnadmin info foo
> > | Path: foo
> > | UUID: d7ac1088-da18-0410-849e-888fbd42cb43
> > | Repository Format: 3
> > | Compatible With Version: 1.1.0
> > | Filesystem Type: fsfs
> > | Filesystem Format: 1
> > | FSFS Sharded: no
> > | FSFS Logical Addressing: yes
> > | Configuration File: foo/db/fsfs.conf
> >
> > Indeed it lists Logical Addressing 'yes'.
> 
> This is a bug that has been fixed recently.  The fix will be available in
> the next patch release of Subversion 1.9:
> 
> https://svn.apache.org/r1720015
> https://svn.apache.org/r1743454
> 
> 
> Regards,
> Evgeny Kotkov

Ah, I had missed that. Thanks!

Re: Invalid character in hex checksum?

[Johan Corveleyn]

>> You should rather let the computer spend some time dealing with the dump
>> and load process, instead of spending your own time working around problems
>> and not even knowing if the result of your workarounds will be OK.
>
> Will have to plan a maintenance window then.
> Gah. :)

You can do this with a very small maintenance window. The trick is to
dump+load to a new location, while the old repository is still
accessible (for checkouts and commits). After this is done (can take
hours, or even days, whatever) you note the last revision which was
loaded (or check the revision number with 'svnlook youngest
newrepos'), and start another dump+load where you dump with
'--incremental -rNEXTREV:HEAD' (where NEXTREV is the next revision
that needs to be dumped).

You can iterate over this as long as you keep the old repository open
... At the end you make the original repository inaccessible for a
couple of minutes, while you enable the new one (Caveat: if you move
your new repos in the same disk location as the old one, and you use
Apache httpd to serve it, make sure you restart httpd to reset its
caches).

Hint: for a large repo I strongly suggest building the new repository
(the target of your 'svnadmin load') on very fast storage, even
ramdisk if possible (to copy it over to fixed disk afterwards). It's
the 'svnadmin load' part that is very time-consuming right now (this
will probably be much improved in svn 1.10, with the
--no-flush-to-disk option for 'svnadmin load' [1]).

To be precise, your commands might be:

1) svnadmin create NEWREPOS
(maybe create it on a ramdisk)
2) svnadmin dump -M 1024 OLDREPOS | svnadmin load -M 1024 NEWREPOS
(initial dump+load; you might want to pass -q to dump and/or load
to make it more quiet)
(the -M 1024 gives the process 1024 MB extra ram for caching)
3) svnlook youngest NEWREPOS
(last rev that was loaded -> NEXTREV is this last rev + 1)
4) svnadmin dump --incremental -rNEXTREV:HEAD -M 1024 | svnadmin load
-M 1024 NEWRPOS
5) Make OLDREPOS read-only or completely unavailable
6) Possibly repeat 4) (if new commits happened after 4)
7) Put NEWREPOS online

At my company we recently did a dump+load from a old svn 1.5
repository ("Repository format: 5; Filesystem Type: fsfs; Filesystem
Format: 3; Sharded but unpacked) to the brand new FSFS format 7 (new
in svn 1.9). It went fine with this procedure. Our largest repos was
15 GB with 328000 revisions. We created the new repository on a
ramdisk, the loading was finished in 6 hours. After that we ran
'svnadmin pack' (still on ramdisk), and then copied it to fixed disk.

Some things to watch out for:

- Dump+load does not preserve locks (in REPOS/db/locks), hooks (in
REPOS/hooks) and configuration files (in REPOS/conf). For those, a 'cp
-rp SOURCE TARGET' works well (but this is a good time to review your
hooks and conf files to make sure they are still fine). Make sure the
source repository is offline while you copy the locks, and those might
otherwise be changed in mid-flight.

- You might run into:
> svnadmin: E125005: Invalid property value found in dumpstream; consider 
> repairing the
> source or using --bypass-prop-validation while loading.
>
> svnadmin: E125005: Cannot accept non-LF line endings in 'svn:log' property

You can try to repair this in the source repository (with svnadmin
setrevprop) -- I'll post separately about that -- or you might simply
ignore this minor corruption by using --bypass-prop-validation for
'svnadmin load' (you can always repair this later in the new
repository).

- You might run into:
> svnadmin: E125005: Invalid property value found in dumpstream; consider 
> repairing the source or using --bypass-prop-validation while loading.
> svnadmin: E125005: Cannot accept non-LF line endings in 'svn:ignore' property

This is more difficult to repair, because 'svn:ignore' is not a
revision property (like svn:log, which can be manipulated with
svnadmin setrevprop), but a *versioned property* (so it's part of
history). Again, you can ignore this with --bypass-prop-validation.
But since this is a corruption "in history", this can only be repaired
with a dump+load, so this might be a good time to try and fix this (or
you'll run into this again in the future). To repair it (which is what
we did), you can use svndumptool [2]. But it only works on dump
*files*, not as part of a pipe. So what we did was: dump that single
(corrupt) revision to a file, repaired it ('svndumptool.py eolfix-prop
svn:ignore svn.dump svn.dump.repaired'), loaded that single dumpfile,
and then continued with a new "piped" command (like step (4) above).


[1] http://svn.apache.org/viewvc?view=revision&revision=1736357
[2] https://github.com/jwiegley/svndumptool

-- 
Johan

Re: Invalid character in hex checksum?

[Johan Corveleyn]

On Thu, Jun 16, 2016 at 12:49 PM, Johan Corveleyn  wrote:
...
> To be precise, your commands might be:
>
> 1) svnadmin create NEWREPOS
> (maybe create it on a ramdisk)
> 2) svnadmin dump -M 1024 OLDREPOS | svnadmin load -M 1024 NEWREPOS
> (initial dump+load; you might want to pass -q to dump and/or load

I forgot that you might have to use the "old svnadmin" from the old
svn version that can still read your repository, on the 'svnadmin
dump' side, to fix your corruption problem. So that won't have the -M
option. But apart from that, the rest should work fine.

-- 
Johan

RE: SVN upgrade

[Somashekarappa, Anup (CWM-NR)]

Hello,

Is the pkgconfig related to apr or apr-util or it is independent of it?

[USER@server subversion-1.9.4]$ make install
/usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig
/usr/bin/install: cannot change permissions of `/usr/local/share/pkgconfig': No 
such file or directory
make: *** [install-fsmod-lib] Error 1


From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: 2016, June, 15 8:32 AM
To: users@subversion.apache.org
Subject: Re: SVN upgrade

Hi,

Hello,

Thank you for your quick response.

I am able to proceed further but stuck at

[USER@server subversion-1.9.4]$ make install
/usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig
/usr/bin/install: cannot change permissions of `/usr/local/share/pkgconfig': No 
such file or directory
make: *** [install-fsmod-lib] Error 1
I take it you already troubleshooted the issue yourself and ruled out the 
obvious candidates like missing pkgconfig, missing permissions, and everything 
else google would point out in the first few links when searching the web for 
that error message, right?
If so, knowing your linux distribution would be useful.




From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: 2016, June, 15 8:04 AM
To: users@subversion.apache.org
Subject: Re: SVN upgrade

On 6/15/2016 1:50 PM, Somashekarappa, Anup (CWM-NR) wrote:

Hi,

I am trying t compile the source code to upgrade from SVN 1.7 to 1.9.4 but I am 
getting the below error.

Could you please send the steps for upgrading since I couldn’t find any good 
document in web ?

I am trying to follow the steps mentioned in 
http://svn.apache.org/repos/asf/subversion/trunk/INSTALL .

And I want to upgrade in Linux

[USER@server subversion-1.9.4]$ sh autogen.sh
: command not found:
: command not found:
: command not found:
': not a valid identifiert: `CDPATH
: command not found:
'utogen.sh: line 35: syntax error near unexpected token `in
'utogen.sh: line 35: `  case "$1" in
Given the output you have here, I take it you downloaded the source as a 
tarball instead of getting it directly form the repository. In this case, 
please follow the instructions in INSTALL under II.A instead II.B.
I.e. run
./configure
make
make install




--

Regards,

Stefan Hett

___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.




--

Regards,

Stefan Hett

Re: Invalid character in hex checksum?

[Sander Smeenk]

Quoting Johan Corveleyn (jcor...@gmail.com):

> > 2) svnadmin dump -M 1024 OLDREPOS | svnadmin load -M 1024 NEWREPOS
> I forgot that you might have to use the "old svnadmin" from the old
> svn version that can still read your repository, on the 'svnadmin
> dump' side, to fix your corruption problem. So that won't have the -M
> option. But apart from that, the rest should work fine.

Thanks for your extensive dump/load guide!
That might help ease our "pain". ;)

I'll go and discuss these options in our team and see where we'll get!

Thanks, all that took time to answer!

-Sndr.
-- 
| If a chemist dies, you barium.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

Re: SVN upgrade

[Stefan Hett]

On 6/16/2016 1:05 PM, Somashekarappa, Anup (CWM-NR) wrote:


Hello,

Is the pkgconfig related to apr or apr-util or it is independent of it?

Maybe someone else who's more familiar with building SVN on Linux can 
provide you some more details on this. From the install doc it's 
suggested that pkg-config is an optional dependency which is used to 
find appropriate options used at build time and is also required by 
other (optional) dependencies like Qt4, D-Bus, KDELibs 4, etc.



[USER@server subversion-1.9.4]$ make install

/usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig

/usr/bin/install: cannot change permissions of 
`/usr/local/share/pkgconfig': No such file or directory


make: *** [install-fsmod-lib] Error 1

*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* 2016, June, 15 8:32 AM
*To:* users@subversion.apache.org
*Subject:* Re: SVN upgrade

Hi,

Hello,

Thank you for your quick response.

I am able to proceed further but stuck at

[USER@server subversion-1.9.4]$ make install

/usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig

/usr/bin/install: cannot change permissions of
`/usr/local/share/pkgconfig': No such file or directory

make: *** [install-fsmod-lib] Error 1

I take it you already troubleshooted the issue yourself and ruled out 
the obvious candidates like missing pkgconfig, missing permissions, 
and everything else google would point out in the first few links when 
searching the web for that error message, right?

If so, knowing your linux distribution would be useful.


*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* 2016, June, 15 8:04 AM
*To:* users@subversion.apache.org 
*Subject:* Re: SVN upgrade

On 6/15/2016 1:50 PM, Somashekarappa, Anup (CWM-NR) wrote:

Hi,

I am trying t compile the source code to upgrade from SVN 1.7 to
1.9.4 but I am getting the below error.

Could you please send the steps for upgrading since I couldn’t
find any good document in web ?

I am trying to follow the steps mentioned in
_http://svn.apache.org/repos/asf/subversion/trunk/INSTALL_.

And I want to upgrade in Linux

[USER@server subversion-1.9.4]$ sh autogen.sh

: command not found:

: command not found:

: command not found:

': not a valid identifiert: `CDPATH

: command not found:

'utogen.sh: line 35: syntax error near unexpected token `in

'utogen.sh: line 35: `  case "$1" in

Given the output you have here, I take it you downloaded the source as 
a tarball instead of getting it directly form the repository. In this 
case, please follow the instructions in INSTALL under II.A instead II.B.

I.e. run
./configure
make
make install



--
Regards,
Stefan Hett

___

This email is intended only for the use of the individual(s) to whom 
it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This 
e-mail in error, please advise immediately and delete the original 
message.
This message may have been altered without your or our knowledge and 
the sender does not accept any liability for any errors or omissions 
in the message.


Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas 
aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des 
renseignements qu'il contient par une personne autre que le (les) 
destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser 
immédiatement, par retour de courriel ou par un autre moyen.


--
Regards,
Stefan Hett



--
Regards,
Stefan Hett

Re: Invalid character in hex checksum?

[Doug Robinson]

One thing to remember: if revision properties are being changed (i.e. the
pre-revprop-change hook allows them) then those changes will need to be
captured and replayed into the loaded repository "somehow" or changes to
revisions prior to -rNEXTREV will be lost.

On Thu, Jun 16, 2016 at 6:49 AM, Johan Corveleyn  wrote:

> >> You should rather let the computer spend some time dealing with the dump
> >> and load process, instead of spending your own time working around
> problems
> >> and not even knowing if the result of your workarounds will be OK.
> >
> > Will have to plan a maintenance window then.
> > Gah. :)
>
> You can do this with a very small maintenance window. The trick is to
> dump+load to a new location, while the old repository is still
> accessible (for checkouts and commits). After this is done (can take
> hours, or even days, whatever) you note the last revision which was
> loaded (or check the revision number with 'svnlook youngest
> newrepos'), and start another dump+load where you dump with
> '--incremental -rNEXTREV:HEAD' (where NEXTREV is the next revision
> that needs to be dumped).
>
> You can iterate over this as long as you keep the old repository open
> ... At the end you make the original repository inaccessible for a
> couple of minutes, while you enable the new one (Caveat: if you move
> your new repos in the same disk location as the old one, and you use
> Apache httpd to serve it, make sure you restart httpd to reset its
> caches).
>
> Hint: for a large repo I strongly suggest building the new repository
> (the target of your 'svnadmin load') on very fast storage, even
> ramdisk if possible (to copy it over to fixed disk afterwards). It's
> the 'svnadmin load' part that is very time-consuming right now (this
> will probably be much improved in svn 1.10, with the
> --no-flush-to-disk option for 'svnadmin load' [1]).
>
> To be precise, your commands might be:
>
> 1) svnadmin create NEWREPOS
> (maybe create it on a ramdisk)
> 2) svnadmin dump -M 1024 OLDREPOS | svnadmin load -M 1024 NEWREPOS
> (initial dump+load; you might want to pass -q to dump and/or load
> to make it more quiet)
> (the -M 1024 gives the process 1024 MB extra ram for caching)
> 3) svnlook youngest NEWREPOS
> (last rev that was loaded -> NEXTREV is this last rev + 1)
> 4) svnadmin dump --incremental -rNEXTREV:HEAD -M 1024 | svnadmin load
> -M 1024 NEWRPOS
> 5) Make OLDREPOS read-only or completely unavailable
> 6) Possibly repeat 4) (if new commits happened after 4)
> 7) Put NEWREPOS online
>
> At my company we recently did a dump+load from a old svn 1.5
> repository ("Repository format: 5; Filesystem Type: fsfs; Filesystem
> Format: 3; Sharded but unpacked) to the brand new FSFS format 7 (new
> in svn 1.9). It went fine with this procedure. Our largest repos was
> 15 GB with 328000 revisions. We created the new repository on a
> ramdisk, the loading was finished in 6 hours. After that we ran
> 'svnadmin pack' (still on ramdisk), and then copied it to fixed disk.
>
> Some things to watch out for:
>
> - Dump+load does not preserve locks (in REPOS/db/locks), hooks (in
> REPOS/hooks) and configuration files (in REPOS/conf). For those, a 'cp
> -rp SOURCE TARGET' works well (but this is a good time to review your
> hooks and conf files to make sure they are still fine). Make sure the
> source repository is offline while you copy the locks, and those might
> otherwise be changed in mid-flight.
>
> - You might run into:
> > svnadmin: E125005: Invalid property value found in dumpstream; consider
> repairing the
> > source or using --bypass-prop-validation while loading.
> >
> > svnadmin: E125005: Cannot accept non-LF line endings in 'svn:log'
> property
>
> You can try to repair this in the source repository (with svnadmin
> setrevprop) -- I'll post separately about that -- or you might simply
> ignore this minor corruption by using --bypass-prop-validation for
> 'svnadmin load' (you can always repair this later in the new
> repository).
>
> - You might run into:
> > svnadmin: E125005: Invalid property value found in dumpstream; consider
> repairing the source or using --bypass-prop-validation while loading.
> > svnadmin: E125005: Cannot accept non-LF line endings in 'svn:ignore'
> property
>
> This is more difficult to repair, because 'svn:ignore' is not a
> revision property (like svn:log, which can be manipulated with
> svnadmin setrevprop), but a *versioned property* (so it's part of
> history). Again, you can ignore this with --bypass-prop-validation.
> But since this is a corruption "in history", this can only be repaired
> with a dump+load, so this might be a good time to try and fix this (or
> you'll run into this again in the future). To repair it (which is what
> we did), you can use svndumptool [2]. But it only works on dump
> *files*, not as part of a pipe. So what we did was: dump that single
> (corrupt) revision to a file, repaired it ('svndumptool.py eolfix-prop
> svn:ignore svn.dump svn.d

What's up with the SVN 1.9 manual?

[Doug Robinson]

Folks:

Does anyone know if (or when) svnbook.red-bean.com is going to
update/support SVN 1.9 ?  It is still listing SVN 1.7 as "current", SVN 1.8
as "nightly" and SVN 1.9 is nowhere to be seen.

Thank you.

Doug
-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: What's up with the SVN 1.9 manual?

[Stefan Sperling]

On Thu, Jun 16, 2016 at 01:51:08PM -0400, Doug Robinson wrote:
> Folks:
> 
> Does anyone know if (or when) svnbook.red-bean.com is going to
> update/support SVN 1.9 ?  It is still listing SVN 1.7 as "current", SVN 1.8
> as "nightly" and SVN 1.9 is nowhere to be seen.
> 
> Thank you.
> 
> Doug
> -- 
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

The svnbook project has a separate mailing list here:
http://www.red-bean.com/pipermail/svnbook-dev/
That list might be a better place for your question.

The book is a volunteer project. It has been lagging behind Subversion
development for a long time. It all depends on what our volunteers put in.
The project is certainly not dead - the above mailing list shows activity.
But there aren't many people actively working on the book at present.

Re: SVN upgrade

[Ryan Schmidt]

On Jun 16, 2016, at 6:05 AM, Somashekarappa, Anup (CWM-NR) wrote:

> Is the pkgconfig related to apr or apr-util or it is independent of it?
>  
> [USER@server subversion-1.9.4]$ make install
> /usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig
> /usr/bin/install: cannot change permissions of `/usr/local/share/pkgconfig': 
> No such file or directory
> make: *** [install-fsmod-lib] Error 1

/usr/local/share/pkgconfig should probably exist. If it doesn't, you might want 
to create it.

You probably want to be running "make install" with elevated privileges, e.g. 
"sudo make install".

Re: Invalid character in hex checksum?

[Johan Corveleyn]

On Thu, Jun 16, 2016 at 7:42 PM, Doug Robinson
 wrote:
>
> One thing to remember: if revision properties are being changed (i.e. the 
> pre-revprop-change hook allows them) then those changes will need to be 
> captured and replayed into the loaded repository "somehow" or changes to 
> revisions prior to -rNEXTREV will be lost.
>

Ah yes, good catch. That's indeed something to watch out for, if your
repository is still writable with revprop-changes enabled, while
you're running the initial dump+load. So either make sure the
pre-revprop-change hook is "closed" while you're running the initial
dump+load, or keep a log of all changed revision properties (write
them to a log file from your post-revprop-change hook or something)
and transfer them to the new repository afterwards (for instance using
'svnlook log' and 'svnadmin setlog').

-- 
Johan

Re: What's up with the SVN 1.9 manual?

[Pavel Lyalyakin]

Hello Doug,

On Thu, Jun 16, 2016 at 8:51 PM, Doug Robinson
 wrote:
>
> Folks:
>
> Does anyone know if (or when) svnbook.red-bean.com is going to update/support 
> SVN 1.9 ?  It is still listing SVN 1.7 as "current", SVN 1.8 as "nightly" and 
> SVN 1.9 is nowhere to be seen.

We've been working on finishing SVNBook 1.8 lately and the process is
currently in the beginning of the read-thru stage. As soon as the
read-thru is complete, we are going to start with SVNBook 1.9.

If you are willing to help, are familiar with the book and its
development environment (I hope so), feel free to send patches. ;)

P.S. And yes, the mailing list
http://www.red-bean.com/pipermail/svnbook-dev/ is the right place to
discuss the book and its status.

--
With best regards,
Pavel Lyalyakin
VisualSVN Team

RE: Performance Decrease After Moving Working Copy to Another Machine

[Brandon Eusebio]

Hello Johan,

Thank you so much for your response! It was incredibly helpful and clear. 

You were correct in the fact that my "tar" command was not preserving the 
correct modified timestamps. It turns out that the default tar format is GNU, 
which only supports timestamp up to a granularity of seconds 
(https://bugs.launchpad.net/duplicity/+bug/696614). I added a flag 
"--format=posix" to get the necessary nanosecond timestamp needed for 
Subversion.

If it is helpful for your future reference, the linux command to get precise 
access + modify + change timestamps is the "stat" command.

You have been an awesome help. Thanks again!

All the best,
Brandon

-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: Thursday, June 16, 2016 12:35 AM
To: Brandon Eusebio 
Cc: users@subversion.apache.org
Subject: Re: Performance Decrease After Moving Working Copy to Another Machine

On Wed, Jun 15, 2016 at 11:36 PM, Brandon Eusebio  wrote:
> Hello,
>
>
>
> I am trying to move/copy a Subversion (version 1.8.10) working copy 
> from one linux machine to another. From researching similar 
> questions/answers, this seems possible by simply moving the entire 
> folder (along with the .svn subdirectory). I have implemented a 
> solution that performs this copy using tar.
>
>
>
> On source machine:
>
> `tar -cpz -f checkout_directory.tar.gz checkout_directory`
>
>
>
> On destination machine (after copy of the tarball):
>
> `tar -xpz -f checkout_directory.tar.gz`
>
>
>
> This achieves the goal of moving the working copy to the destination 
> machine; however the performance of svn operations becomes drastically 
> slower. For example, a `svn status` on the original machine takes < 1 
> minute, but takes ~1 hour on the destination machine. The entire 
> folder is ~50GB, but these timings include clearing out the linux 
> buffers/caches and similar hardware/load on each machine.
>
>
>
> I can mitigate the performance hit by doing an `svn cleanup` on the 
> destination machine, but this operation also takes ~1 hour. I suspect 
> this updates the change times that Subversion uses to determine 
> whether or not local changes have been made 
> (http://svn.haxx.se/users/archive-2003-11/0595.shtml).
>

Yes, for the working copy to work optimally, the mtimes (last modification 
time) of the files need to correspond exactly to the corresponding values in 
the svn metadata (stored in .svn/wc.db, an sqlite database). Running 'svn 
cleanup' will fix this, because it corrects the metadata in wc.db to note the 
correct mtimes.

I'm not sure if your tar commands precisely preserve the mtimes of the files 
(googling around for tar and mtime brings up several discussions where "it 
should, but sometimes it doesn't"). And with precisely, I mean "up to the 
nanosecond, exactly the same timestamp as on the original file". Also: what 
sometimes happens is that there is a difference in filesystems between source 
and target of the copy, so they might have different timestamp granularity on 
the filesystem level, leading to slightly different timestamps.

I would suggest you try to verify the timestamps for some files in the source 
and target working copies, and their corresponding values in
wc.db:

1) Run "ls" with some option to display precise timestamps (on Solaris you get 
"full-iso" time-style by running "ls -E", don't know the exact equivalent for 
linux). Check this on source and target. If they are different then there is 
your problem.

2) To double check, you can also see what the value in wc.db is, by running a 
query with sqlite3 like this:

sqlite3 -header -column wc.db "select local_relpath, last_mod_time from 
nodes where local_relpath='path/to/file'"

You'll probably have to convert the value you get there (it will be in 
milliseconds or microseconds "since epoch"), for instance use this:
http://currentmillis.com/

HTH,
--
Johan

Re: Invalid character in hex checksum?

[Gert Kello]

>
>
> Posts found on Google suggested that doing an 'svnadmin dump' with an
> older version of svn, and 'svnadmin load'-ing that on a new svn system,
> essentially recreating the repostory from scratch, helps recover from
> this situation which is indeed true.
> This is all nice if a repo has a few commits but, as one might
> imagine, a repo from 2006 has a gazillion of commits. The one i'm
> testing with is really small, but i also have a repo that's 28GB on
> disk and i don't really feel like dumping and loading that.
>
>
You can use scnsync to create an upgraded copy of repository as well.
Especially useful if You want to migrate repository to new machine.

Gert