svn upgrade with dump/load

[Stümpfig , Thomas]

Hi all,
I plan to upgrade a 250GB Repository from 1.5 to 1.7. As I learned from other 
threads in this list, it is wise to dump and load the repository in order to 
bring everything to the latest features.
I have to keep the revision numbers and transaction dates.

Now svn dump and load offer some flexibility. And my server has 32GB Memory and 
16 Cores.
Now, in order to optimize the migration process would it be worth to split the 
dump into multiple dumps? And if yes, would you use delta dumps?


Thomas Stümpfig

running 2 update commands on one working copy at the same time

[Jan Keirse]

Hello,

I've got 2 batch processes, one compile CHUI files and another compiling 
WIN32 files. They use the same working copy and update the working copy 
before starting. 
I wonder if this is safe: if the 2 update commands run at the same time, 
will this cause issues? So far it appears to work just fine, but I'd 
rather be sure than sorry. 


ps.: Both compilers run on the same machine and just invoke svn.exe 
--non-interactive --accept theirs-full --depth infinity update 
c:\workingcopyname, so there won't be a problem with incompatible clients, 
the client is the same. I just wonder if I could have problems with a 
locked working copy or something like that. The working copy is only used 
for compiling, there are never any changes in the working copy. SVN Server 
& Client: 1.6.17, OS WIN32, server = Apache.

Kind Regards,

JAN KEIRSE
ICT-DEPARTMENT
Software quality & Systems: Software Engineer

 DISCLAIMER 

http://www.tvh.com/newen2/emaildisclaimer/default.html 

"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."

Re: svn upgrade with dump/load

[Ulrich Eckhardt]

Am 27.09.2011 09:06, schrieb Stümpfig, Thomas:

I plan to upgrade a 250GB Repository from 1.5 to 1.7. As I learned
from other threads in this list, it is wise to dump and load the
repository in order to bring everything to the latest features. I
have to keep the revision numbers and transaction dates.


Those will be preserved, as will be the UUID of your repository, unless 
your target repo is not empty. What is not preserved is the 
configuration area and hook scripts, but you can simply copy them over.




Now svn dump and load offer some flexibility. And my server has 32GB
Memory and 16 Cores.Now, in order to optimize the migration process
would it be worth to split the dump into multiple dumps?


I don't think so. The point is that the bottleneck is probably the 
channel connecting your computer to its hard disk(s). There, it would be 
worth using one hard disk to read from and another to write to, via 
different interfaces, of course.


Uli
**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

RE: svnsync fails to backup a particular revision of one repository

[David Aldrich]

Hi Daniel

Thanks for your reply. We will consider that possibility.

BR

David

> -Original Message-
> From: Daniel Shahaf [mailto:danie...@elego.de]
> Sent: 26 September 2011 23:51
> To: David Aldrich
> Cc: users@subversion.apache.org
> Subject: Re: svnsync fails to backup a particular revision of one repository
> 
> Permissions issues suggest you're thinking of the source repository, but the
> error might well come from the target repository.
> 
> David Aldrich wrote on Mon, Sep 26, 2011 at 13:48:26 +:
> > Hi
> >
> > We have a problem with svnsync.  We run:
> >
> > svnsync sync /svn/
> >
> > periodically to backup our master repositories to an offsite  server.
> >
> > For one particular repository, this command fails to sync one particular
> revision. We see:
> >
> > Copied properties for revision 3125.
> > Transmitting file data ..
> > Committed revision 3126.
> > Copied properties for revision 3126.
> > Transmitting file data . svnsync:
> > '/svn//branches//' path not found
> >
> > As far as we can tell, svnsync does have permission to access this path.  We
> run svn 1.6.17.
> >
> > Please can anyone suggest how to fix this?
> >
> > Best regards
> >
> > David
> >
> 
> 
>  Click
> https://www.mailcontrol.com/sr/Z8mqdxkXdN7TndxI!oX7UkEBkbd6cai+o2
> WYcWlv+NzXmpy3ia+HpPy1LiLzIw9mrpKQrgjPFD+Od!jBVaBGJg==  to report
> this email as spam.

Re: running 2 update commands on one working copy at the same time

[Stephen Butler]

On Sep 27, 2011, at 9:20 , Jan 
 wrote:

> Hello,
> 
> I've got 2 batch processes, one compile CHUI files and another compiling 
> WIN32 files. They use the same working copy and update the working copy 
> before starting. 
> I wonder if this is safe: if the 2 update commands run at the same time, 
> will this cause issues? So far it appears to work just fine, but I'd 
> rather be sure than sorry. 
> 
> 
> ps.: Both compilers run on the same machine and just invoke svn.exe 
> --non-interactive --accept theirs-full --depth infinity update 
> c:\workingcopyname, so there won't be a problem with incompatible clients, 
> the client is the same. I just wonder if I could have problems with a 
> locked working copy or something like that. The working copy is only used 
> for compiling, there are never any changes in the working copy. SVN Server 
> & Client: 1.6.17, OS WIN32, server = Apache.


Subversion operations that modify the working copy, such as update, use
a Subversion-internal "administrative" locking to ensure that the operations
don't collide.

It's possible that build process B runs an update while build proces A is
already compiling.  Then the effective source code of build A might
include files from different revisions, which is difficult to reproduce.

Regards,
Steve

--
Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

Betr.: Re: running 2 update commands on one working copy at the same time

[Jan Keirse]

Stephen Butler  schreef op 27/09/2011 10:58:26:

> 
> On Sep 27, 2011, at 9:20 , Jan 
>  wrote:
> 
> > Hello,
> > 
> > I've got 2 batch processes, one compile CHUI files and another 
compiling 
> > WIN32 files. They use the same working copy and update the working 
copy 
> > before starting. 
> > I wonder if this is safe: if the 2 update commands run at the same 
time, 
> > will this cause issues? So far it appears to work just fine, but I'd 
> > rather be sure than sorry. 
> > 
> > 
> > ps.: Both compilers run on the same machine and just invoke svn.exe 
> > --non-interactive --accept theirs-full --depth infinity update 
> > c:\workingcopyname, so there won't be a problem with incompatible 
clients, 
> > the client is the same. I just wonder if I could have problems with a 
> > locked working copy or something like that. The working copy is only 
used 
> > for compiling, there are never any changes in the working copy. SVN 
Server 
> > & Client: 1.6.17, OS WIN32, server = Apache.
> 
> 
> Subversion operations that modify the working copy, such as update, use
> a Subversion-internal "administrative" locking to ensure that the 
operations
> don't collide.

Great. 
 
> It's possible that build process B runs an update while build proces A 
is
> already compiling.  Then the effective source code of build A might
> include files from different revisions, which is difficult to reproduce.

I am aware of this risk but it won't cause problems in our setup: If this 
happened a second compile would be triggered automatically. 
I was only worried the working copy could get corrupted causing the update 
to fail, but if subversion handles this I should be safe. 
 DISCLAIMER 

http://www.tvh.com/newen2/emaildisclaimer/default.html 

"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."

svn undo

[Richard Cavell]

Hi everyone,

 Is there any chance that svn could include an undo subcommand? Instead of 
compelling us to do 'reverse merges'.

 Richard

re: svn upgrade with dump/load

[Stefan Fuhrmann]

Stümpfig, Thomas > 
wrote:


I plan to upgrade a 250GB Repository from 1.5 to 1.7. As I learned 
from other threads in this list, it is wise to dump and load the 
repository in order to bring everything to the latest features.

I have to keep the revision numbers and transaction dates.

Now svn dump and load offer some flexibility. And my server has 32GB 
Memory and 16 Cores.
Now, in order to optimize the migration process would it be worth to 
split the dump into multiple dumps? And if yes, would you use delta 
dumps?



Hi Thomas,

You can use the 1.7 binaries for both, dump and load.
Version 1.7 svnadmin has a new "-M" parameter that
allows for using large caches for this kind of operations.

On your machine, you could set 16G aside for the
migration and do something along the lines of:

svnadmin dump -M 8000 $old | svnadmin load -M 8000 $new

The performance limiting part is the replaying of all
commits on the load side. If possible, make the /db/transactions
and /db/txn-protorevs of the target point to some RAM disk.

-- Stefan^2.

Re: Betr.: Re: running 2 update commands on one working copy at the same time

[Johan Corveleyn]

On Tue, Sep 27, 2011 at 11:05 AM, Jan Keirse  wrote:
> Stephen Butler  schreef op 27/09/2011 10:58:26:
>
>>
>> On Sep 27, 2011, at 9:20 , Jan
>>  wrote:
>>
>> > Hello,
>> >
>> > I've got 2 batch processes, one compile CHUI files and another
> compiling
>> > WIN32 files. They use the same working copy and update the working
> copy
>> > before starting.
>> > I wonder if this is safe: if the 2 update commands run at the same
> time,
>> > will this cause issues? So far it appears to work just fine, but I'd
>> > rather be sure than sorry.
>> >
>> >
>> > ps.: Both compilers run on the same machine and just invoke svn.exe
>> > --non-interactive --accept theirs-full --depth infinity update
>> > c:\workingcopyname, so there won't be a problem with incompatible
> clients,
>> > the client is the same. I just wonder if I could have problems with a
>> > locked working copy or something like that. The working copy is only
> used
>> > for compiling, there are never any changes in the working copy. SVN
> Server
>> > & Client: 1.6.17, OS WIN32, server = Apache.
>>
>>
>> Subversion operations that modify the working copy, such as update, use
>> a Subversion-internal "administrative" locking to ensure that the
> operations
>> don't collide.
>
> Great.
>
>> It's possible that build process B runs an update while build proces A
> is
>> already compiling.  Then the effective source code of build A might
>> include files from different revisions, which is difficult to reproduce.
>
> I am aware of this risk but it won't cause problems in our setup: If this
> happened a second compile would be triggered automatically.
> I was only worried the working copy could get corrupted causing the update
> to fail, but if subversion handles this I should be safe.

It won't get corrupted, because of the internal locking that Stephen
mentioned. But the second update, being blocked by the "lock" of the
first one, will error out. So your build scripts should be prepared to
handle that (even if only by exiting with a sensible error message or
something like that).

-- 
Johan

Backups of only the portion of the repository data

[Waseem Shahzad]

Hi guys!

Is it possible to take the Backups of only the
portion of the repository data. Like my svn database has four folders in
the repository. I only want to take backup of third folder. Possible?

 

 

Thanks

Re: subversion 1.6.17 bug with linking on static library system

[Alan Hourihane]

Hi all,

I didn't get any response to this, but did anything happen ?

Thanks,

Alan.

On 09/07/11 09:02, Alan Hourihane wrote:
> Hi,
>
> I'm building subversion 1.6.17 on a static library only system and
> there's some link problems.
>
> First is neon, it's link order is this
>
> -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm -lneon
>
> whereas it should be...(note -lneon at the start)
>
> -lneon -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm
>
> Secondly, when linking libapr-1 it's not checking with pkgconfig for
> other dependencies, which on my system depends on libuuid.a and that's
> not pulled in either.
>
> I'll glad test any fixes.
>
> Thanks,
>
> Alan.

Re: FAQ entry needs improvement

[Ulrich Eckhardt]

Am 26.09.2011 23:42, schrieb Ryan Schmidt:

On Sep 26, 2011, at 05:20, Daniel Shahaf wrote:


https://svn.apache.org/repos/asf/subversion/site/publish/faq.html#undo

It's the most frequently asked question on IRC, and I'm tried of
invoking the 'undo' factoid, perhaps people can help patch that entry to
make it clearer?

Thanks.


<  wayita>  undo is done using 'svn merge' or 'svn copy':
  
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo


What would make the FAQ entry clearer?



The FAQ entry mentions merging or copying, while the referenced entry in 
the documentation only explains merging.


I just tried to write how to use "svn copy" to bring an old revision to 
the top, but I actually can't do that from my head. I know that I can 
delete the current head and then copy the old version to the same 
location using revisions while using repo URLs. I can imagine the same 
in a single commit using a working copy. Both should be easy for any SVN 
user.


What I'm not sure is how that would work if I tried to copy a directory 
on top of another directory, i.e. if the directory wouldn't be copied 
into the other directory instead. Since it's hard to undo revisions, I'd 
wish for the FAQ to give me a recipe for that or tell me it's impossible.



Cheers!

Uli
**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

[SOLVED] Error "not under version control" when trying to reintegrate branch

[Gurvan Le Guernic]

   Hi,
 This morning everything works fine. I assume the problem was due to
the fact that I got read/write access on the root of the repository
the same day I tried to reintegrate the branch and those rights were
not well propagated yet.
 Still, the error message claiming that my branch was not under
version control, was not really helpful if it was really an access
right problem.
   Thanks,
   Gurvan

Re: svn undo

[Stefan Sperling]

On Tue, Sep 27, 2011 at 03:55:54AM -0400, Richard Cavell wrote:
> Hi everyone,
> 
>  Is there any chance that svn could include an undo subcommand? Instead of 
> compelling us to do 'reverse merges'.

What would you expect this new command to do?
Would it just run a reverse merge, or would it do more?

Would the syntax for this new command differ significantly from
the existing merge command?

  svn merge -c-42 .

Would you like to type this instead?

  svn undo -c42 .

If the 'undo' command is just a thin wrapper around 'merge' you might as well
provide an 'svnundo' script for users that are uncomfortable with using
'svn merge'.

Note that some IDE integrations already provide an 'undo this revision'
feature which runs a reverse merge. I believe TortoiseSVN has one, too.

svn blame: how to see reverted line?

[Kaz Kylheku]

Hi all,

I'm running "svn blame" to on a file but not getting useful results
in this particular instance, because I'm trying to find out when
a change was reverted.

I will substitute an example to simplify.

Suppose I have a file which was created (revision 1) by user bob.
Then at revision 50, a kludge was introduced by alice work around some 
bug

elsewhere.

Now, the file is at line 100, and the kludge has been reverted.
It turns out that this had been done by mike in rev 75, but I don't
know that, which is why I'm running "svn blame".

But I'm getting this:

1  bob original line
1  bob original line
1  bob original line

Although it is true that the resembles the original written by bob,
thanks to the revert, I want blame to show me who touched something
last.

1  bob original line
75 mike original line
1  bob original line

The line may be the original one, but it's mike who put it there,
reverting alice's rev 50 workaround.

Re: svn undo

[Richard Cavell]

Well consider the svn cp subcommand, which does nothing more than delete/add. 
One day svn cp could do more than that.

 Likewise, svn undo could initially do nothing more than svn merge (and put a - 
sign in front of the revision number), but perhaps one day do more.

 Richard
- Original Message -
From: Stefan Sperling
Sent: 09/27/11 10:03 AM
To: Richard Cavell
Subject: Re: svn undo

 On Tue, Sep 27, 2011 at 03:55:54AM -0400, Richard Cavell wrote: > Hi everyone, 
> > Is there any chance that svn could include an undo subcommand? Instead of 
compelling us to do 'reverse merges'. What would you expect this new command to 
do? Would it just run a reverse merge, or would it do more? Would the syntax 
for this new command differ significantly from the existing merge command? svn 
merge -c-42 . Would you like to type this instead? svn undo -c42 . If the 
'undo' command is just a thin wrapper around 'merge' you might as well provide 
an 'svnundo' script for users that are uncomfortable with using 'svn merge'. 
Note that some IDE integrations already provide an 'undo this revision' feature 
which runs a reverse merge. I believe TortoiseSVN has one, too.

svn mkdir --> Conflict - what can cause this?

[Jim Garrison]

We have an automatic (Hudson) build that runs every night.  It starts by making 
a tag directory into which it will then copy the current build root folder.  
Last night, the mkdir failed:

svn --username [obfuscated] --password [obfuscated] --no-auth-cache mkdir 
--parents http://svn/repos/troux/autobuild/trunk/20110926_233057 -m"create 
autobuild tag directory"

svn: Conflict at '/autobuild/trunk/20110926_233057'

The job was rerun this morning without making any changes and it had no problem 
with the mkdir.  I can guarantee that the directory didn't exist in the 
repository prior to the mkdir command.

The svn server is running on Linux (Fedora 14) and is at version 1.6.16
The client is on Linux (Fedora 14) and is at version 1.6.17

Ideas?

Re: svn mkdir --> Conflict - what can cause this?

[Mark Phippard]

On Tue, Sep 27, 2011 at 10:54 AM, Jim Garrison  wrote:
> We have an automatic (Hudson) build that runs every night.  It starts by 
> making a tag directory into which it will then copy the current build root 
> folder.  Last night, the mkdir failed:
>
> svn --username [obfuscated] --password [obfuscated] --no-auth-cache mkdir 
> --parents http://svn/repos/troux/autobuild/trunk/20110926_233057 -m"create 
> autobuild tag directory"
>
> svn: Conflict at '/autobuild/trunk/20110926_233057'
>
> The job was rerun this morning without making any changes and it had no 
> problem with the mkdir.  I can guarantee that the directory didn't exist in 
> the repository prior to the mkdir command.
>
> The svn server is running on Linux (Fedora 14) and is at version 1.6.16
> The client is on Linux (Fedora 14) and is at version 1.6.17

It can happen if any change is committed beneath the autobuild
directory in the short window from which the code retrieves its
version and then commits the next transaction.  It is real easy to see
this problem if you are using mirrors and the write-thru proxy
feature.  On a single server, it seems like it would just require
perfect bad-timing.

If your logs give you a timestamp when the command failed, you ought
to be able to run svn log and see if there was another commit at the
same time.


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: AW: Does Subversion get slower over time?

[Cory Riddell]

Markus,

On 9/26/2011 1:45 AM, Markus Schaber wrote:
> Just a suggestion: Set up a second repository just aside your primary
> one, and put the 3rd party stuff there. You can then use svn:externals
> to include the libraries in your regular project trees.

Using externals seems to be the way to go. Last night I moved our
repository from C:\SvnRepo to C:\CompanyName\SvnRepo and had everybody
do a relocate this morning. That seems to have gone fine. Step 2 is
adding more repositories under C:\CompanyName that will be referenced
via externals.

Thanks for the advice.

Cory

Re: Betr.: Re: running 2 update commands on one working copy at the same time

[Daniel Shahaf]

Johan Corveleyn wrote on Tue, Sep 27, 2011 at 11:17:43 +0200:
> It won't get corrupted, because of the internal locking that Stephen
> mentioned. But the second update, being blocked by the "lock" of the
> first one, will error out.

'svn cleanup' will remove any locks it sees, and Badness may happen if
the process who installed that lock is still running (as opposed to have
crashed).

Though, perhaps 'svn cleanup' does (or should) only remove locks when
--force is passed...?

Re: FAQ entry needs improvement

[Daniel Shahaf]

Ulrich Eckhardt wrote on Tue, Sep 27, 2011 at 11:57:42 +0200:
> Am 26.09.2011 23:42, schrieb Ryan Schmidt:
> >On Sep 26, 2011, at 05:20, Daniel Shahaf wrote:
> >
> >>https://svn.apache.org/repos/asf/subversion/site/publish/faq.html#undo
> >>
> >>It's the most frequently asked question on IRC, and I'm tried of
> >>invoking the 'undo' factoid, perhaps people can help patch that entry to
> >>make it clearer?
> >>
> >>Thanks.
> >>
> >>
> >><  wayita>  undo is done using 'svn merge' or 'svn copy':
> >>  
> >> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo
> >
> >What would make the FAQ entry clearer?
> 
> 
> The FAQ entry mentions merging or copying, while the referenced
> entry in the documentation only explains merging.
> 
> I just tried to write how to use "svn copy" to bring an old revision
> to the top, but I actually can't do that from my head. I know that I
> can delete the current head and then copy the old version to the
> same location using revisions while using repo URLs. I can imagine
> the same in a single commit using a working copy. Both should be
> easy for any SVN user.
> 
> What I'm not sure is how that would work if I tried to copy a
> directory on top of another directory, i.e. if the directory
> wouldn't be copied into the other directory instead. Since it's hard
> to undo revisions, I'd wish for the FAQ to give me a recipe for that
> or tell me it's impossible.
> 

In 1.7 you can do such directory replacements in the working copy.

You can always do:

svnmucc -m "The trunk is dead, long live the trunk!" rm $URL/trunk cp HEAD 
$URL/branches/foo $URL/trunk

Re: subversion 1.6.17 bug with linking on static library system

[Daniel Shahaf]

Alan Hourihane wrote on Tue, Sep 27, 2011 at 10:56:02 +0100:
> Hi all,
> 
> I didn't get any response to this, but did anything happen ?
> 
> Thanks,
> 
> Alan.
> 
> On 09/07/11 09:02, Alan Hourihane wrote:
> > Hi,
> >
> > I'm building subversion 1.6.17 on a static library only system and
> > there's some link problems.
> >
> > First is neon, it's link order is this
> >
> > -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm -lneon
> >
> > whereas it should be...(note -lneon at the start)
> >
> > -lneon -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm
> >

Ouch.  Can you test the 1.7 release candidates?  I remember some
build.conf patches to reorder the libraries this summer.

> > Secondly, when linking libapr-1 it's not checking with pkgconfig for
> > other dependencies, which on my system depends on libuuid.a and that's
> > not pulled in either.
> >

I believe configure uses apr-1-config, not pkg-config.
See build/ac-macros/

> > I'll glad test any fixes.
> >
> > Thanks,
> >
> > Alan.
> 

Re: Backups of only the portion of the repository data

[Daniel Shahaf]

svndumpfilter or svnsync can do this

Waseem Shahzad wrote on Tue, Sep 27, 2011 at 05:34:12 -0400:
> Hi guys!
> 
> Is it possible to take the Backups of only the
> portion of the repository data. Like my svn database has four folders in
> the repository. I only want to take backup of third folder. Possible?
> 
>  
> 
>  
> 
> Thanks
> 

Re: subversion 1.6.17 bug with linking on static library system

[Alan Hourihane]

On 09/27/11 19:59, Daniel Shahaf wrote:
> Alan Hourihane wrote on Tue, Sep 27, 2011 at 10:56:02 +0100:
>> Hi all,
>>
>> I didn't get any response to this, but did anything happen ?
>>
>> Thanks,
>>
>> Alan.
>>
>> On 09/07/11 09:02, Alan Hourihane wrote:
>>> Hi,
>>>
>>> I'm building subversion 1.6.17 on a static library only system and
>>> there's some link problems.
>>>
>>> First is neon, it's link order is this
>>>
>>> -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm -lneon
>>>
>>> whereas it should be...(note -lneon at the start)
>>>
>>> -lneon -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm
>>>
> Ouch.  Can you test the 1.7 release candidates?  I remember some
> build.conf patches to reorder the libraries this summer.
>

I'll take a look.

>>> Secondly, when linking libapr-1 it's not checking with pkgconfig for
>>> other dependencies, which on my system depends on libuuid.a and that's
>>> not pulled in either.
>>>
> I believe configure uses apr-1-config, not pkg-config.
> See build/ac-macros/
>

O.k., but subversion still gets it wrong then, as uuid is listed from
apr-1-config --libs.

Alan.

Re: subversion 1.6.17 bug with linking on static library system

[Alan Hourihane]

On 09/27/11 19:59, Daniel Shahaf wrote:
> Alan Hourihane wrote on Tue, Sep 27, 2011 at 10:56:02 +0100:
>> Hi all,
>>
>> I didn't get any response to this, but did anything happen ?
>>
>> Thanks,
>>
>> Alan.
>>
>> On 09/07/11 09:02, Alan Hourihane wrote:
>>> Hi,
>>>
>>> I'm building subversion 1.6.17 on a static library only system and
>>> there's some link problems.
>>>
>>> First is neon, it's link order is this
>>>
>>> -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm -lneon
>>>
>>> whereas it should be...(note -lneon at the start)
>>>
>>> -lneon -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm
>>>
> Ouch.  Can you test the 1.7 release candidates?  I remember some
> build.conf patches to reorder the libraries this summer.

Just so you know subversion 1.6.15 worked. So I'm not sure if these
patches you mention predate that or not.

Alan.

Re: subversion 1.6.17 bug with linking on static library system

[Daniel Shahaf]

Alan Hourihane wrote on Tue, Sep 27, 2011 at 20:12:09 +0100:
> On 09/27/11 19:59, Daniel Shahaf wrote:
> > Alan Hourihane wrote on Tue, Sep 27, 2011 at 10:56:02 +0100:
> >> Hi all,
> >>
> >> I didn't get any response to this, but did anything happen ?
> >>
> >> Thanks,
> >>
> >> Alan.
> >>
> >> On 09/07/11 09:02, Alan Hourihane wrote:
> >>> Hi,
> >>>
> >>> I'm building subversion 1.6.17 on a static library only system and
> >>> there's some link problems.
> >>>
> >>> First is neon, it's link order is this
> >>>
> >>> -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm -lneon
> >>>
> >>> whereas it should be...(note -lneon at the start)
> >>>
> >>> -lneon -lz -lssl -lcrypto -lz   -lxml2 -lz -lpthread -liconv -lm
> >>>
> > Ouch.  Can you test the 1.7 release candidates?  I remember some
> > build.conf patches to reorder the libraries this summer.
> 
> Just so you know subversion 1.6.15 worked. So I'm not sure if these
> patches you mention predate that or not.

There are no relevant differences to build.conf between 1.6.15 and
1.6.17.

You may want to consult the history of the 1.6.x branch to determine the
regression.

> 
> Alan.

perl SVN::Client bug

[Thompson, Thomas J]

Hi,

I'm an intermediate perl developer with lots to learn, but I think I've found 
an issue with the perl subversion bindings that I'd like to pass by you folks 
to ensure it's not just operator error.  I would give you the version I'm 
working with, but I see no VERSION variable in the SVN::Client module.  What 
version information would be useful?

I tried to subclass SVN::Client, but I found that function calls were failing 
with type errors. I brought this up in this thread on perlmonks:
http://www.perlmonks.org/?node_id=928123

I was seeing errors that look like this:
TypeError in method 'svn_client_ls', argument 2 of type 'char const *'

I found out this section of code handles arguments for calls to the svn 
functions:
# import methods into our name space and wrap them in a closure
# to support method calling style $ctx->log()
foreach my $function (@_all_fns)
{
no strict 'refs';
my $real_function = \&{"SVN::_Client::svn_client_$function"};
*{"SVN::Client::$function"} = sub
{
my ($self, $ctx);
my @args;

# Don't shift the first param if it isn't a SVN::Client
# object.  This lets the old style interface still work.
# And is useful for functions like url_from_path which
# don't take a ctx param, but might be called in method
# invocation style or as a normal function.
for (my $index = $[; $index <= $#_; $index++)
{
if (ref($_[$index]) eq 'SVN::Client')
{
($self) = splice(@_,$index,1);
$ctx = $self->{'ctx'};
last;
} elsif (ref($_[$index]) eq '_p_svn_client_ctx_t') {
$self = undef;
($ctx) = splice(@_,$index,1);
last;
}
}

The problem here is this line:
if (ref($_[$index]) eq 'SVN::Client')

This breaks if you attempt to subclass SVN::Client to add functionality.  The 
result is type errors because the invocant is not removed from the function 
arguments before being passed through to the svn api.  This should instead be:

if (UNIVERSAL::isa($_[$index], 'SVN::Client')



What should I do from here to ensure it is addressed?  I'd like to help out the 
perl/svn community.



Thomas

Re: perl SVN::Client bug

[Geoff Rowell]

On Sep 27, 2011, at 4:25 PM, "Thompson, Thomas J"  
wrote:

> Hi,
> 
>  
> 
> I’m an intermediate perl developer with lots to learn, but I think I’ve found 
> an issue with the perl subversion bindings that I’d like to pass by you folks 
> to ensure it’s not just operator error.  I would give you the version I’m 
> working with, but I see no VERSION variable in the SVN::Client module.  What 
> version information would be useful?
> 
>  
> 
> I tried to subclass SVN::Client, but I found that function calls were failing 
> with type errors. I brought this up in this thread on perlmonks:
> 
> http://www.perlmonks.org/?node_id=928123
> 
>  
> 
> I was seeing errors that look like this:
> 
> TypeError in method 'svn_client_ls', argument 2 of type 'char const *'
> 
>  
> 
> I found out this section of code handles arguments for calls to the svn 
> functions:
> 
> # import methods into our name space and wrap them in a closure
> 
> # to support method calling style $ctx->log()
> 
> foreach my $function (@_all_fns)
> 
> {
> 
> no strict 'refs';
> 
> my $real_function = \&{"SVN::_Client::svn_client_$function"};
> 
> *{"SVN::Client::$function"} = sub
> 
> {
> 
> my ($self, $ctx);
> 
> my @args;
> 
>  
> 
> # Don't shift the first param if it isn't a SVN::Client
> 
> # object.  This lets the old style interface still work.
> 
> # And is useful for functions like url_from_path which
> 
> # don't take a ctx param, but might be called in method
> 
> # invocation style or as a normal function.
> 
> for (my $index = $[; $index <= $#_; $index++)
> 
> {
> 
> if (ref($_[$index]) eq 'SVN::Client')
> 
> {
> 
> ($self) = splice(@_,$index,1);
> 
> $ctx = $self->{'ctx'};
> 
> last;
> 
> } elsif (ref($_[$index]) eq '_p_svn_client_ctx_t') {
> 
> $self = undef;
> 
> ($ctx) = splice(@_,$index,1);
> 
> last;
> 
> }
> 
> }
> 
>  
> 
> The problem here is this line:
> 
> if (ref($_[$index]) eq 'SVN::Client')
> 
>  
> 
> This breaks if you attempt to subclass SVN::Client to add functionality.  The 
> result is type errors because the invocant is not removed from the function 
> arguments before being passed through to the svn api.  This should instead be:
> 
> if (UNIVERSAL::isa($_[$index], 'SVN::Client')
>  
> What should I do from here to ensure it is addressed?  I’d like to help out 
> the perl/svn community.

Or even better,

  $_[$index]->isa('SVN::Client')

-Geoff

Re: perl SVN::Client bug

[Daniel Shahaf]

Thompson, Thomas J wrote on Tue, Sep 27, 2011 at 13:25:04 -0700:
> Hi,
> 
> I'm an intermediate perl developer with lots to learn, but I think
> I've found an issue with the perl subversion bindings that I'd like to
> pass by you folks to ensure it's not just operator error.  I would
> give you the version I'm working with, but I see no VERSION variable
> in the SVN::Client module.  What version information would be useful?
> 

svn_client_version()

(Though, perhaps we should just be setting $VERSION...)

> I tried to subclass SVN::Client, but I found that function calls were failing 
> with type errors. I brought this up in this thread on perlmonks:
> http://www.perlmonks.org/?node_id=928123
> 
> I was seeing errors that look like this:
> TypeError in method 'svn_client_ls', argument 2 of type 'char const *'
> 
> I found out this section of code handles arguments for calls to the svn 
> functions:
> # import methods into our name space and wrap them in a closure
> # to support method calling style $ctx->log()
> foreach my $function (@_all_fns)
> {
> no strict 'refs';
> my $real_function = \&{"SVN::_Client::svn_client_$function"};
> *{"SVN::Client::$function"} = sub
> {
> my ($self, $ctx);
> my @args;
> 
> # Don't shift the first param if it isn't a SVN::Client
> # object.  This lets the old style interface still work.
> # And is useful for functions like url_from_path which
> # don't take a ctx param, but might be called in method
> # invocation style or as a normal function.
> for (my $index = $[; $index <= $#_; $index++)
> {
> if (ref($_[$index]) eq 'SVN::Client')
> {
> ($self) = splice(@_,$index,1);
> $ctx = $self->{'ctx'};
> last;
> } elsif (ref($_[$index]) eq '_p_svn_client_ctx_t') {
> $self = undef;
> ($ctx) = splice(@_,$index,1);
> last;
> }
> }
> 
> The problem here is this line:
> if (ref($_[$index]) eq 'SVN::Client')
> 
> This breaks if you attempt to subclass SVN::Client to add functionality.  The 
> result is type errors because the invocant is not removed from the function 
> arguments before being passed through to the svn api.  This should instead be:
> 
> if (UNIVERSAL::isa($_[$index], 'SVN::Client')
> 
> 
> 
> What should I do from here to ensure it is addressed?  I'd like to help out 
> the perl/svn community.
> 

(This is just an answer to your process question; I haven't reviewed the
issue to determine whether or not I agree with your proposed fix.)

Send a patch against subversion/bindings/swig/perl/native/Client.pm.

See http://subversion.apache.org/patches

Thanks!

RE: perl SVN::Client bug

[Thompson, Thomas J]

Or even better,

  $_[$index]->isa('SVN::Client')

This will break if $_[$index] is not a package or object reference, which is 
exactly what this portion of the code appears to deal with.  Best keep it the 
other way ☺


From: Geoff Rowell [mailto:geoff.row...@gmail.com]
Sent: Tuesday, September 27, 2011 2:14 PM
To: Thompson, Thomas J
Cc: users@subversion.apache.org
Subject: Re: perl SVN::Client bug


On Sep 27, 2011, at 4:25 PM, "Thompson, Thomas J" 
mailto:thomas.j.thomp...@intel.com>> wrote:
Hi,

I’m an intermediate perl developer with lots to learn, but I think I’ve found 
an issue with the perl subversion bindings that I’d like to pass by you folks 
to ensure it’s not just operator error.  I would give you the version I’m 
working with, but I see no VERSION variable in the SVN::Client module.  What 
version information would be useful?

I tried to subclass SVN::Client, but I found that function calls were failing 
with type errors. I brought this up in this thread on perlmonks:
http://www.perlmonks.org/?node_id=928123

I was seeing errors that look like this:
TypeError in method 'svn_client_ls', argument 2 of type 'char const *'

I found out this section of code handles arguments for calls to the svn 
functions:
# import methods into our name space and wrap them in a closure
# to support method calling style $ctx->log()
foreach my $function (@_all_fns)
{
no strict 'refs';
my $real_function = \&{"SVN::_Client::svn_client_$function"};
*{"SVN::Client::$function"} = sub
{
my ($self, $ctx);
my @args;

# Don't shift the first param if it isn't a SVN::Client
# object.  This lets the old style interface still work.
# And is useful for functions like url_from_path which
# don't take a ctx param, but might be called in method
# invocation style or as a normal function.
for (my $index = $[; $index <= $#_; $index++)
{
if (ref($_[$index]) eq 'SVN::Client')
{
($self) = splice(@_,$index,1);
$ctx = $self->{'ctx'};
last;
} elsif (ref($_[$index]) eq '_p_svn_client_ctx_t') {
$self = undef;
($ctx) = splice(@_,$index,1);
last;
}
}

The problem here is this line:
if (ref($_[$index]) eq 'SVN::Client')

This breaks if you attempt to subclass SVN::Client to add functionality.  The 
result is type errors because the invocant is not removed from the function 
arguments before being passed through to the svn api.  This should instead be:

if (UNIVERSAL::isa($_[$index], 'SVN::Client')



What should I do from here to ensure it is addressed?  I’d like to help out the 
perl/svn community.

Or even better,

  $_[$index]->isa('SVN::Client')

-Geoff

ISO/FDA certified?

[D. Ramsey]

I am planning to use Subversion to control documents used in the development of 
medical instrumentation.  Does anyone know if Subversion has been approved or 
certified by ISO or FDA for this us?

Thanks,
Dave Ramsey

Re: ISO/FDA certified?

[Stefan Sperling]

On Tue, Sep 27, 2011 at 02:31:31PM -0700, D. Ramsey wrote:
> I am planning to use Subversion to control documents used in the development 
> of medical instrumentation.  Does anyone know if Subversion has been approved 
> or certified by ISO or FDA for this us?
> 

There are medical (and other) companies using Subversion in an FDA-certified
process. I don't know anything about details of the certification procedure
though. I just know that they got certified somehow.

Re: ISO/FDA certified?

[Mark Phippard]

On Tue, Sep 27, 2011 at 6:01 PM, Stefan Sperling  wrote:
> On Tue, Sep 27, 2011 at 02:31:31PM -0700, D. Ramsey wrote:
>> I am planning to use Subversion to control documents used in the development 
>> of medical instrumentation.  Does anyone know if Subversion has been 
>> approved or certified by ISO or FDA for this us?
>>
>
> There are medical (and other) companies using Subversion in an FDA-certified
> process. I don't know anything about details of the certification procedure
> though. I just know that they got certified somehow.

This is the best message I recall reading on this subject:

http://svn.haxx.se/users/archive-2009-07/0981.shtml

It sounds to me like the process with which you use your tools is what
needs to be validated more so than the tools themselves.  This makes
sense to me, since just about any tool can be used in proper and
improper ways.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: ISO/FDA certified?

[Stefan Sperling]

On Tue, Sep 27, 2011 at 06:11:10PM -0400, Mark Phippard wrote:
> This is the best message I recall reading on this subject:
> 
> http://svn.haxx.se/users/archive-2009-07/0981.shtml

Hah, thanks for digging that up, Mark.
I didn't even remember that I had posted this :)

Re: svn upgrade with dump/load

[Daniel Shahaf]

Wouldn't it also be useful to pass --deltas to 'svnadmin dump'?

I should note the advice below only applies to FSFS-backed repositories.

Stefan Fuhrmann wrote on Tue, Sep 27, 2011 at 11:11:45 +0200:
> >Stümpfig, Thomas  >>
> >wrote:
> >
> >I plan to upgrade a 250GB Repository from 1.5 to 1.7. As I learned
> >from other threads in this list, it is wise to dump and load the
> >repository in order to bring everything to the latest features.
> >I have to keep the revision numbers and transaction dates.
> >
> >Now svn dump and load offer some flexibility. And my server has
> >32GB Memory and 16 Cores.
> >Now, in order to optimize the migration process would it be worth
> >to split the dump into multiple dumps? And if yes, would you use
> >delta dumps?
> >
> Hi Thomas,
> 
> You can use the 1.7 binaries for both, dump and load.
> Version 1.7 svnadmin has a new "-M" parameter that
> allows for using large caches for this kind of operations.
> 
> On your machine, you could set 16G aside for the
> migration and do something along the lines of:
> 
> svnadmin dump -M 8000 $old | svnadmin load -M 8000 $new
> 
> The performance limiting part is the replaying of all
> commits on the load side. If possible, make the /db/transactions
> and /db/txn-protorevs of the target point to some RAM disk.
> 
> -- Stefan^2.

AW: "Subversion encountered a serious problem." error details

[Markus Schaber]

Hi, Jason,

It seems that you discovered two different issuses.

Von: Jason Holland [mailto:jholl...@a-cc.com] 
[Screenshot]
> I was checking in latest code before leaving.

That first screenshot shows an assertion failure in TortoiseSVN 1.7 beta 2. It 
is likely to be fixed in the latest build of TortoiseSVN (you try that one), 
and if not, you come back with that issue. :-)

[Screenshot]
> Only noticeable difference between today (and also in the last few days) as 
> compared to previously is that my Tortoise app is not supported by the 
> subversion server software.  See below.  Though, I have not experienced the 
> above issue until 15 minutes ago.  

The second issue seems to have mislead you, it is not about Tortoise, and not 
about the server.

The problem is that the aforementioned TortoiseSVN 1.7 beta 2 (or another 
1.7-based client you used on that working copy) upgraded your working copy to 
the new 1.7 format. And it seems that you still have an 1.6 based version of 
AnkhSVN installed in your visual studio, which cannot cope with the new 1.7 
format.

The solution for this to upgrade AnkhSVN to the newest 1.7-based build 
(http://ankhsvn.open.collab.net/daily) or wait until the first 1.7-based 
version is released.

In my opinion, the error message clearly describes that second issue, so it 
would be nice if you could tell us what in that message did you mislead to 
believe it is about the server refusing your client, so the developers can 
improve on that message. :-)

Best regards

Markus Schaber
-- 
___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915