Re: upgrading source code in local repository

[Ulrich Eckhardt]

On Wednesday 03 August 2011, you wrote:
> On Aug 1, 2011, at 05:31, Ulrich Eckhardt wrote:
> > On Friday 29 July 2011, Brecht Ameije wrote:
> >> I read the referred page in the book, indeed: the script
> >> svn_load_dirs.pl is exactly what I need. It implements the steps that I
> >> did by hand.
> > 
> > There is one thing that took me a while to understand when starting to
> > use that: This doesn't preserve your local changes. Instead, after
> > uploading a new upstream version, you have to apply your local changes
> > again. Merging helps though.
> 
> I think perhaps you still misunderstand. Correct, svn_load_dirs.pl does not
> preserve your local changes. That's not its job. You never run
> svn_load_dirs.pl on directories or parts of the repository that contain
> any changes. You only run them on pristine copies of the vendor software.
> 
> Example:
> 
> svn mkdir $URL/vendor
> 
> /vendor in the repository will contain copies of all the third-party
> software you want to keep track of. You will never make your own changes
> to that code in this part of the repository. These will always represent
> exact copies of the upstream source.
> 
> Let's say you want to keep track of a third-party software called foo. It's
> currently at version 1.1. You download the tarball of version 1.1 and you
> import it into the repository at this path:
> 
> svn mkdir $URL/vendor/foo
> svn import /path/to/foo-1.1 $URL/vendor/foo/current
> 
> "current" is analogous to the "trunk" of a project that you're developing,
> but it's not called "trunk" here because "trunk" is a place where you make
> changes, and you're not going to be making any changes here.

Yes I am. You might question whether it is reasonable to make them here, but 
it doesn't matter. The point is that you use svn_load_dirs not in order to 
just mirror the upstream sources locally, you could use a simple shared 
directory for that. No, you typically want to modify those sources, like adapt 
them to your company's build system or similar requirements.

Now, these changes must be applied to any upstream release before you can use 
it and the astonishing part to me was that svn_load_dirs doesn't help you at 
all with that. So if you (like we do here) modify "current", you have to 
manually re-apply all those changes after you uploaded a new version. It's no 
big deal, but I at first expected svn_load_dirs to help me with that.


> Now you make a copy of current and call it 1.1:
> 
> svn cp $URL/vendor/foo/current $URL/vendor/foo/1.1
> 
> This is like a "tag" in a project that you're developing.

svn_load_dirs already makes a tag for you, if you want.


> Finally, you copy version 1.1 into another location in the repository where
> you want to use it. Let's say that foo will be used inside a project
> you're developing called bar, so perhaps you run:
> 
> svn cp $URL/vendor/foo/1.1 $URL/bar/trunk/libs/foo

Ahem, no? :-) I don't copy things around just in order to use them. Libraries 
are simply installed and are then available for any project that needs them. 
This restricts changes to be made in just one place. But of course, you can do 
it like that if you want to, I just wanted to point out that there is no One 
True Way(tm).


Cheers!

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/

**
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: upgrading source code in local repository

[Andreas Krey]

On Tue, 09 Aug 2011 09:20:17 +, Ulrich Eckhardt wrote:
...
> 
> Yes I am. You might question whether it is reasonable to make them here, but 
> it doesn't matter. The point is that you use svn_load_dirs not in order to 
> just mirror the upstream sources locally, you could use a simple shared 
> directory for that. No, you typically want to modify those sources, like 
> adapt 
> them to your company's build system or similar requirements.
> 
> Now, these changes must be applied to any upstream release before you can use 
> it and the astonishing part to me was that svn_load_dirs doesn't help you at 
> all with that.

No, 'svn' ist supposed to help you with that. You keep a branch that only
contains the upstream updates, and repeatedly merge that into the branch
that you use to modify the vendor's sources to suit your needs. The
process of integration your modifications with a new upstream release
is called 'merging', which is something svn can do itself.

What svn can't do is exactly the history-preserving directory mirroring
*into* subversions, that, and only that, is what svn_load_dirs is for:
Change a branch to exactly the state an external directory represents.

Also, how do you think svn_load_dirs *should* do what you request? In
your scenario it works on a sandbox that contains the last vendor
release along with your changes on one hand, and it has the current
vendor release on the other hand. How should it decide what of the
changes between the two are vendor updates (to be taken from the new
vendor release) and what are your changes (to be kept)?

Simply to do that it would not only need to look into the svn history
of your single branch, but also discern which of the commits were
for your local adaption and which were vendor updates.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: 1.7 'svn upgrade' issue on windows vista

[Kurt Pruenner]

On 09.08.2011 08:54, Ulrich Eckhardt wrote:
> I don't think the folder containing the root of a WC should have to
> have the exact same name as the folder in the repository it
> corresponds to. As this is a feature to me, I hope that 1.7 isn't
> going to break this.

It is a bug, and it has been fixed:

On 05.08.2011 13:32, Bert Huijben wrote:
> Thanks for reporting (and the nice reproduction recipe).
> 
> I just fixed the issue in r1154165.
> 
> (This patch won't make beta 3, but I'll nominate it for backport for
> 1.7.0)
> 
> Bert

So no worries... :)

-- 
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
...It might be written "Mindfuck", but it's spelt "L-A-I-N"...

svn wc&repo performance

[Andreas Krey]

On Mon, 01 Aug 2011 07:39:59 +, Les Mikesell wrote:
...
> SQLlite has years of development and a good reputation for robust behavior. 

I don't doubt that.

> I'd expect it to be hard to match its performance and reliability without 
> an equally long development cycle.

We don't want an SQL server, we want an svn client.

A tool used must not only perform, but also be the proper tool.

> I don't quite understand the point of re-implementing something that is 
> already developed on top of cross platform open source libraries.

Using SQL is a tradeoff between developer time and user time; any
implementation of SQL is obviously not as performant as a domain-specific
serialization can be. Given the large user base of svn, some more thought
in that direction may have been in order.

But I may be barking up the wrong tree. I built svn 1.7 and ran my
small 'second consecutive commit fails' test script with that. It's
not the local operations, but those that act on the repository (here:
file:///...) that take ridiculously long. Each commit and do-nothing
'svn up' takes about a second, for the five files involved. I've come
to expect such operations to be instantaneous.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Checksum failed after using sed to modify paths in dump file in spite of using ^

[Peter Pommelich]

Hi everbody,

I wrote to this mailing list a few days ago (I had some questions regarding how 
to migrate a repository). I'm still working in this...

The current problem I have is this:
I have to modify some paths (trunk/meta/trunk => trunk) in the dump file 
created with 'svnadmin dump'. I did the modification of 'Node-path' and 
'Node-copyfrom-path' with sed. But after loading this modified dump file into 
the new repo, I got a checksum error for a jar file. If I load the unmodified 
dump file into the new repository everything is fine.

This is the way I created the dump file and modified the paths:
>> cat DumpCompleteSource.dump | svndumpfilter include  trunk/meta/trunk/_build 
>> trunk/meta/trunk/_client-libs > Dump_only_trunk.dump
>> cat Dump_only_trunk.dump | sed -e 's,^Node-path: trunk/meta/,Node-path: ,' > 
>> Dump_only_trunk_NodePathFixed.dump
>> cat Dump_only_trunk_NodePathFixed.dump | sed -e 's,^Node-copyfrom-path: 
>> trunk/meta/,Node-copyfrom-path: ,' > 
>> Dump_only_trunk_NodePathFixed_NodeCopyFromFixed.dump

I also tried to concatenate all commands using pipes and omitting creating 
files, but I still get the checksum .

Does anyone know why the usage of sed mess the checksums/content up? For each 
substitution I used the beginning-of-ile marker '^' so there should'nt be any 
content modified right?
Maybe this is also important: the OS is SunOS 5.10

Kind regards and thanks (again),
pete
___
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

Re: upgrading source code in local repository

[Ulrich Eckhardt]

On Tuesday 09 August 2011, Andreas Krey wrote:
> On Tue, 09 Aug 2011 09:20:17 +, Ulrich Eckhardt wrote:
> ...
> 
> > Yes I am. You might question whether it is reasonable to make them here,
> > but it doesn't matter. The point is that you use svn_load_dirs not in
> > order to just mirror the upstream sources locally, you could use a
> > simple shared directory for that. No, you typically want to modify those
> > sources, like adapt them to your company's build system or similar
> > requirements.
> > 
> > Now, these changes must be applied to any upstream release before you can
> > use it and the astonishing part to me was that svn_load_dirs doesn't
> > help you at all with that.
> 
> No, 'svn'[Note: I'm assuming you meant svn_load_dirs here] ist supposed to
> help you with that. You keep a branch that only contains the upstream
> updates, and repeatedly merge that into the branch that you use to
> modify the vendor's sources to suit your needs. The process of integration
> your modifications with a new upstream release is called 'merging', which
> is something svn can do itself.
> 
> What svn can't do is exactly the history-preserving directory mirroring
> *into* subversions, that, and only that, is what svn_load_dirs is for:
> Change a branch to exactly the state an external directory represents.

Yes, I am fully aware of all that, reread what I said: I warned the OP that 
this is something that initially confused me when I first used svn_load_dirs.

The point is that svn_load_dirs is mentioned as a tool that helps maintaining 
vendor branches. A common task in that context is to update your vendor branch 
from a new upstream release. A requirement there is that local changes are 
preserved through the update. svn_load_dirs doesn't help you with that, it 
only changes "a branch to exactly the state an external directory 
represents.". This is something that confused me when years ago I first 
started creating a vendor branch of something. Reading the docs now, they have 
improved in that aspect.


> Also, how do you think svn_load_dirs *should* do what you request?

Wearing a user's hat, the answer is that I don't care. Yes, this is a rather 
naive approach, but why should I care how it works under the hood? I just need 
my changes preserved!

Now, more practically speaking, I synced a directory to vendor-1.1. I then 
made several changes and then sync to 1.2. The obvious approach is to first 
upload the new 1.2 verbatim and then merge the changes made between the two 
syncs one by one, optionally prompting the user. This is effectively what I do 
manually now and there is no reason it couldn't be done automatically.

I'd even claim that this is superior to the documented approach of merging 
1.1:1.2 into a local branch. The problem is that this is one big change that 
often contains bugfixes that can be contained in the local branch. If upstream 
slightly changed the code, like different formatting, comments, etc, applying 
the big change on top will cause conflicts. Selecting the local changes to 
apply on to of the new 1.2 version manually, possibly adjusting changes in 
between has higher chances of success.

That said, I wouldn't say that it is svn_load_dirs that should do all this. 
Firstly, it is a tool with a very clear goal (sync a directory) and adding 
further features would be just bloat. Secondly, these are just merges and 
those should be easy using _any_ SVN client, so improvements are better put 
there than adding specializations in yet another tool.

> In your scenario it works on a sandbox that contains the last vendor
> release along with your changes on one hand, and it has the current
> vendor release on the other hand. How should it decide what of the
> changes between the two are vendor updates (to be taken from the new
> vendor release) and what are your changes (to be kept)?
> 
> Simply to do that it would not only need to look into the svn history
> of your single branch, but also discern which of the commits were
> for your local adaption and which were vendor updates.

svnsync manages to find out when and where it last synced with, so why 
shouldn't a vendor-branch management tool? You can always add a custom 
property, infer the last sync from the checkin comment or prompt the user.

Cheers!

Uli



-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/

**
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 

Re: svn wc&repo performance

[Stefan Sperling]

On Tue, Aug 09, 2011 at 11:06:43AM +0200, Andreas Krey wrote:
> But I may be barking up the wrong tree. I built svn 1.7 and ran my
> small 'second consecutive commit fails' test script with that. It's
> not the local operations, but those that act on the repository (here:
> file:///...) that take ridiculously long. Each commit and do-nothing
> 'svn up' takes about a second, for the five files involved. I've come
> to expect such operations to be instantaneous.

Which script are you referring to? Can you post it or provide a link?

What platform are you running your test on?

Re: svn wc&repo performance

[Erik Huelsmann]

Hi Andreas,

On Tue, Aug 9, 2011 at 11:06 AM, Andreas Krey  wrote:

> On Mon, 01 Aug 2011 07:39:59 +, Les Mikesell wrote:
> ...
> > SQLlite has years of development and a good reputation for robust
> behavior.
>
> I don't doubt that.
>
> > I'd expect it to be hard to match its performance and reliability without
> > an equally long development cycle.
>
> We don't want an SQL server, we want an svn client.
>
> A tool used must not only perform, but also be the proper tool.
>
> > I don't quite understand the point of re-implementing something that is
> > already developed on top of cross platform open source libraries.
>
> Using SQL is a tradeoff between developer time and user time; any
> implementation of SQL is obviously not as performant as a domain-specific
> serialization can be. Given the large user base of svn, some more thought
> in that direction may have been in order.
>
> But I may be barking up the wrong tree. I built svn 1.7 and ran my
> small 'second consecutive commit fails' test script with that. It's
> not the local operations, but those that act on the repository (here:
> file:///...) that take ridiculously long. Each commit and do-nothing
> 'svn up' takes about a second, for the five files involved. I've come
> to expect such operations to be instantaneous.
>
>
The fact that the 'svn up' takes about a second can't be blamed on SQL Lite
or any other SQL engine. The Subversion client sleeps 1 second to make sure
that it's able to detect changes to files: it does timestamp checks and
returning immediately would allow a short timeframe where modifying the file
would not result in a new timestamp (namely, modifications within the same
second, such as the use by scripts).

Bye,

Erik.

Re: svn wc&repo performance

[Andreas Krey]

On Tue, 09 Aug 2011 11:38:41 +, Stefan Sperling wrote:
...
> Which script are you referring to? Can you post it or provide a link?

This one:

set -xe
rm -rf repo wc
time svnadmin create repo
time svn checkout file:///`pwd`/repo wc
cd wc
mkdir D
touch A D/B D/C E
# svn add . # <- That nuisance 'already under control'...
time svn add A D E
time svn commit -m 'initial'
time svn up
time svn up
date >D/B
date >A
time svn propset blub blah .
#(cd D && svn commit . -m green)
time svn commit D -m green
time svn commit . -m blau

> What platform are you running your test on?

Macbook Pro, not that new. The times are pretty similar on a Sun, as
well as on a linux box.  (Also across svn versions, from 1.5.5 to 1.7)

Output on the latter:
===
+ rm -rf repo wc
+ svnadmin create repo

real0m0.577s
user0m0.004s
sys 0m0.008s
++ pwd
+ svn checkout file:home/krey/svnt/repo wc
Checked out revision 0.

real0m0.672s
user0m0.008s
sys 0m0.004s
+ cd wc
+ mkdir D
+ touch A D/B D/C E
+ svn add A D E
A A
A D
A D/B
A D/C
A E

real0m0.032s
user0m0.004s
sys 0m0.004s
+ svn commit -m initial
Adding A
Adding D
Adding D/B
Adding D/C
Adding E
Transmitting file data 
Committed revision 1.

real0m0.931s
user0m0.016s
sys 0m0.012s
+ svn up
At revision 1.

real0m1.000s
user0m0.000s
sys 0m0.008s
+ svn up
At revision 1.

real0m1.002s
user0m0.000s
sys 0m0.008s
+ date
+ date
+ svn propset blub blah .
property 'blub' set on '.'

real0m0.016s
user0m0.008s
sys 0m0.004s
+ svn commit D -m green
SendingD/B
Transmitting file data .
Committed revision 2.

real0m0.973s
user0m0.004s
sys 0m0.008s
+ svn commit . -m blau
Sending.
svn: Commit failed (details follow):
svn: Directory '/' is out of date

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: svn wc&repo performance

[Stefan Sperling]

On Tue, Aug 09, 2011 at 11:46:06AM +0200, Erik Huelsmann wrote:
> The fact that the 'svn up' takes about a second can't be blamed on SQL Lite
> or any other SQL engine. The Subversion client sleeps 1 second to make sure
> that it's able to detect changes to files: it does timestamp checks and
> returning immediately would allow a short timeframe where modifying the file
> would not result in a new timestamp (namely, modifications within the same
> second, such as the use by scripts).

Good point.

Andreas, to confirm that the sleep for timestamps affects your
measurements you can put this on top of your script:

export SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS=1

Re: svn wc&repo performance

[Andreas Krey]

On Tue, 09 Aug 2011 12:12:17 +, Stefan Sperling wrote:
...
> export SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS=1

ITYM "...AMPS=yes". Then it's running faster (and not apparently corrupt)
indeed, and we're now closing up to git.

I'd like SVN_DO_CONTENT_CHECK_ON_EQUAL_TIMESTAMPS. ;-)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

For a while I was downloading and running the development build of subversion 
1.7.0.  At one revision of the code I started having an issue where svn would 
immediately segfault.  At that time I stopped using 1.7.0 assuming the issue 
would be fixed before release.  Unfortunately I just downloaded the beta2 
release of 1.7.0 and I'm having the same problem.  Interestingly enough I can 
successfully build beta2 on one of our 32bit systems, but I can't use that 
build on our 64 bit systems because it tries to link against the 32bit version 
of libmagic.

It's important to note that I don't get any errors compiling the design.  It's 
just that after I install it I get a segfault when I try and run svn.  
Ironically, if I run svn with no options or invalid options it successfully 
runs, but as soon as I add a valid option like "svn help" it segfaults.  I've 
spent multiple hours trying to compile with different options to my 
LD_LIBRARY_PATH/PATH variables and I've tried to mix up how I build apr, 
apr-util, serf, and neon, but it always results in the same problem.

I am using a very vanilla build process.

Wget
Tar
./get-deps.sh
./configure -prefix=$HOME/local
make && make install

As I've noted I have successfully built a development version of 1.7.0 on our 
64bit systems in the past.

-Mike

Re: Checksum failed after using sed to modify paths in dump file in spite of using ^

[Ryan Schmidt]

On Aug 9, 2011, at 04:16, Peter Pommelich wrote:

> I have to modify some paths (trunk/meta/trunk => trunk) in the dump file 
> created with 'svnadmin dump'. I did the modification of 'Node-path' and 
> 'Node-copyfrom-path' with sed.

Do not use sed to modify a dumpfile; use a tool designed to understand the dump 
format, like svn's own svndumpfilter:

http://svnbook.red-bean.com/en/1.5/svn.ref.svndumpfilter.html

or the independently developed svndumptool:

http://svn.borg.ch/svndumptool/

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Mark Phippard]

On Mon, Aug 8, 2011 at 6:19 PM,  wrote:

> For a while I was downloading and running the development build of
> subversion 1.7.0.  At one revision of the code I started having an issue
> where svn would immediately segfault.  At that time I stopped using 1.7.0
> assuming the issue would be fixed before release.  Unfortunately I just
> downloaded the beta2 release of 1.7.0 and I’m having the same problem.
> Interestingly enough I can successfully build beta2 on one of our 32bit
> systems, but I can’t use that build on our 64 bit systems because it tries
> to link against the 32bit version of libmagic.
>
> ** **
>
> It’s important to note that I don’t get any errors compiling the design.
> It’s just that after I install it I get a segfault when I try and run svn.
> Ironically, if I run svn with no options or invalid options it successfully
> runs, but as soon as I add a valid option like “svn help” it segfaults.
> I’ve spent multiple hours trying to compile with different options to my
> LD_LIBRARY_PATH/PATH variables and I’ve tried to mix up how I build apr,
> apr-util, serf, and neon, but it always results in the same problem.
>
> ** **
>
> I am using a very vanilla build process.
>
> ** **
>
> Wget
>
> Tar
>
> ./get-deps.sh
>
> ./configure –prefix=$HOME/local
>
> make && make install
>
> ** **
>
> As I’ve noted I have successfully built a development version of 1.7.0 on
> our 64bit systems in the past.
>

We see the same problem when compiling our binaries on RHEL 4 64-bit.  We
had to switch to building on RHEL 5.  I do not have the failing binaries
available to test any more.  Maybe it would help if you provided details on
the segfault like a dump or something?  I thought the problem was in our
build process so I did not raise the issue and we do not actually support
RHEL 4 anymore so I did not press it.

-- 
Thanks

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

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Stefan Sperling]

On Mon, Aug 08, 2011 at 04:19:06PM -0600, michael_rytt...@agilent.com wrote:
> For a while I was downloading and running the development build of subversion 
> 1.7.0.  At one revision of the code I started having an issue where svn would 
> immediately segfault.  At that time I stopped using 1.7.0 assuming the issue 
> would be fixed before release.  Unfortunately I just downloaded the beta2 
> release of 1.7.0 and I'm having the same problem.  Interestingly enough I can 
> successfully build beta2 on one of our 32bit systems, but I can't use that 
> build on our 64 bit systems because it tries to link against the 32bit 
> version of libmagic.
> 
> It's important to note that I don't get any errors compiling the design.  
> It's just that after I install it I get a segfault when I try and run svn.  
> Ironically, if I run svn with no options or invalid options it successfully 
> runs, but as soon as I add a valid option like "svn help" it segfaults.  I've 
> spent multiple hours trying to compile with different options to my 
> LD_LIBRARY_PATH/PATH variables and I've tried to mix up how I build apr, 
> apr-util, serf, and neon, but it always results in the same problem.
> 
> I am using a very vanilla build process.
> 
> Wget
> Tar
> ./get-deps.sh
> ./configure -prefix=$HOME/local
> make && make install
> 

This is most likely a problem with your build, not with Subversion
itself. Maybe your build is getting 32bit and 64bit libraries mixed up?

> As I've noted I have successfully built a development version of 1.7.0 on our 
> 64bit systems in the past.

Note that libmagic support was added quite recently (in alpha2).
Does the problem disappear if you pass the --with-libmagic=no
option to configure?

Cannot get a file when deleted

[Adam Tong]

Hi,

When i remove a file from my local copy, I cannot get it from the
repository using the command svn up.

Is there another way to get a recently deleted file? or there is
something wrong in my settings.

Thanks

Re: Cannot get a file when deleted

[Giulio Troccoli]

On 09/08/11 15:40, Adam Tong wrote:

Hi,

When i remove a file from my local copy, I cannot get it from the
repository using the command svn up.

Is there another way to get a recently deleted file? or there is
something wrong in my settings.

Thanks


Did you use the OS to delete the file or Subversion? Did you commit? If 
you can tell as exactly what you did we'd be in a better position to help

Re: Cannot get a file when deleted

[Giulio Troccoli]

On 09/08/11 16:02, Adam Tong wrote:

you are right i used the os, i did not commit after deleting.

On Tue, Aug 9, 2011 at 11:00 AM, Giulio Troccoli
  wrote:

On 09/08/11 15:40, Adam Tong wrote:

Hi,

When i remove a file from my local copy, I cannot get it from the
repository using the command svn up.

Is there another way to get a recently deleted file? or there is
something wrong in my settings.

Thanks

Did you use the OS to delete the file or Subversion? Did you commit? If you
can tell as exactly what you did we'd be in a better position to help



In that case the file should be back. What does svn status say?

And please, Reply-to-all so that the conversation stays on the mailing list

Gulio

Re: Cannot get a file when deleted

[Adam Tong]

svn st gives the that the file was deleted (D) when i do svn up it
does not bring it. But when i did the first sugetion of copy -r 
it worked

sorry about forgeting to reply to all


On Tue, Aug 9, 2011 at 11:03 AM, Giulio Troccoli
 wrote:
>
>
> On 09/08/11 16:02, Adam Tong wrote:
>>
>> you are right i used the os, i did not commit after deleting.
>>
>> On Tue, Aug 9, 2011 at 11:00 AM, Giulio Troccoli
>>   wrote:
>>>
>>> On 09/08/11 15:40, Adam Tong wrote:

 Hi,

 When i remove a file from my local copy, I cannot get it from the
 repository using the command svn up.

 Is there another way to get a recently deleted file? or there is
 something wrong in my settings.

 Thanks
>>>
>>> Did you use the OS to delete the file or Subversion? Did you commit? If
>>> you
>>> can tell as exactly what you did we'd be in a better position to help
>>>
>
> In that case the file should be back. What does svn status say?
>
> And please, Reply-to-all so that the conversation stays on the mailing list
>
> Gulio
>

Re: Cannot get a file when deleted

[Giulio Troccoli]

On 09/08/11 16:18, Adam Tong wrote:

svn st gives the that the file was deleted (D) when i do svn up it
does not bring it. But when i did the first sugetion of copy -r 
it worked

sorry about forgeting to reply to all


On Tue, Aug 9, 2011 at 11:03 AM, Giulio Troccoli
  wrote:


On 09/08/11 16:02, Adam Tong wrote:

you are right i used the os, i did not commit after deleting.

On Tue, Aug 9, 2011 at 11:00 AM, Giulio Troccoli
wrote:

On 09/08/11 15:40, Adam Tong wrote:

Hi,

When i remove a file from my local copy, I cannot get it from the
repository using the command svn up.

Is there another way to get a recently deleted file? or there is
something wrong in my settings.

Thanks

Did you use the OS to delete the file or Subversion? Did you commit? If
you
can tell as exactly what you did we'd be in a better position to help


In that case the file should be back. What does svn status say?

And please, Reply-to-all so that the conversation stays on the mailing list

Gulio



Well, is svn st says it's been deleted than you have use svn to delete 
the file, or Subversion wouldn't know about it. So to restore it you can 
simply use svn revert


Giulio

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

Like I've said, I was able to build subversion 1.7.0 on our 64bit systems in 
the past.  The build flow hasn't changed.  I've put a lot of time into trying 
different options to the build flow and I'm pretty sure that isn't the culprit.

As for your second recommendation, it doesn't look like libmagic can be 
disabled.  The configure script doesn't read the without_libmagic variable 
anywhere.  And the configure script doesn't properly deal with the "no" 
argument.   I just ended up deleting the entire libmagic section in the 
configure script and built subversion that way.  Now at least I can build on a 
32bit system and run the 32bit version of svn on our 64bit systems.

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: Tuesday, August 09, 2011 8:35 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit

On Mon, Aug 08, 2011 at 04:19:06PM -0600, michael_rytt...@agilent.com wrote:
> For a while I was downloading and running the development build of subversion 
> 1.7.0.  At one revision of the code I started having an issue where svn would 
> immediately segfault.  At that time I stopped using 1.7.0 assuming the issue 
> would be fixed before release.  Unfortunately I just downloaded the beta2 
> release of 1.7.0 and I'm having the same problem.  Interestingly enough I can 
> successfully build beta2 on one of our 32bit systems, but I can't use that 
> build on our 64 bit systems because it tries to link against the 32bit 
> version of libmagic.
> 
> It's important to note that I don't get any errors compiling the design.  
> It's just that after I install it I get a segfault when I try and run svn.  
> Ironically, if I run svn with no options or invalid options it successfully 
> runs, but as soon as I add a valid option like "svn help" it segfaults.  I've 
> spent multiple hours trying to compile with different options to my 
> LD_LIBRARY_PATH/PATH variables and I've tried to mix up how I build apr, 
> apr-util, serf, and neon, but it always results in the same problem.
> 
> I am using a very vanilla build process.
> 
> Wget
> Tar
> ./get-deps.sh
> ./configure -prefix=$HOME/local
> make && make install
> 

This is most likely a problem with your build, not with Subversion itself. 
Maybe your build is getting 32bit and 64bit libraries mixed up?

> As I've noted I have successfully built a development version of 1.7.0 on our 
> 64bit systems in the past.

Note that libmagic support was added quite recently (in alpha2).
Does the problem disappear if you pass the --with-libmagic=no option to 
configure?

Re: Cannot get a file when deleted

[Adam Tong]

You are right i just tested when i do revert it is reverted and i can
see it in the file system.

On the other hand, I am sure that i am doing "rm filename" and not svn
delete filename.

Maybe there is a way to configure svn so that it considers rm as
equivalent to svn delete?

Because this is happens in my job and does not in my laptop at home.


On Tue, Aug 9, 2011 at 11:20 AM, Giulio Troccoli
 wrote:
>
>
> On 09/08/11 16:18, Adam Tong wrote:
>>
>> svn st gives the that the file was deleted (D) when i do svn up it
>> does not bring it. But when i did the first sugetion of copy -r 
>> it worked
>>
>> sorry about forgeting to reply to all
>>
>>
>> On Tue, Aug 9, 2011 at 11:03 AM, Giulio Troccoli
>>   wrote:
>>>
>>> On 09/08/11 16:02, Adam Tong wrote:

 you are right i used the os, i did not commit after deleting.

 On Tue, Aug 9, 2011 at 11:00 AM, Giulio Troccoli
     wrote:
>
> On 09/08/11 15:40, Adam Tong wrote:
>>
>> Hi,
>>
>> When i remove a file from my local copy, I cannot get it from the
>> repository using the command svn up.
>>
>> Is there another way to get a recently deleted file? or there is
>> something wrong in my settings.
>>
>> Thanks
>
> Did you use the OS to delete the file or Subversion? Did you commit? If
> you
> can tell as exactly what you did we'd be in a better position to help
>
>>> In that case the file should be back. What does svn status say?
>>>
>>> And please, Reply-to-all so that the conversation stays on the mailing
>>> list
>>>
>>> Gulio
>>>
>
> Well, is svn st says it's been deleted than you have use svn to delete the
> file, or Subversion wouldn't know about it. So to restore it you can simply
> use svn revert
>
> Giulio
>

Re: Cannot get a file when deleted

[Giulio Troccoli]

On 09/08/11 16:28, Adam Tong wrote:

You are right i just tested when i do revert it is reverted and i can
see it in the file system.

On the other hand, I am sure that i am doing "rm filename" and not svn
delete filename.

Maybe there is a way to configure svn so that it considers rm as
equivalent to svn delete?

Because this is happens in my job and does not in my laptop at home.


On Tue, Aug 9, 2011 at 11:20 AM, Giulio Troccoli
  wrote:


On 09/08/11 16:18, Adam Tong wrote:

svn st gives the that the file was deleted (D) when i do svn up it
does not bring it. But when i did the first sugetion of copy -r 
it worked

sorry about forgeting to reply to all


On Tue, Aug 9, 2011 at 11:03 AM, Giulio Troccoli
wrote:

On 09/08/11 16:02, Adam Tong wrote:

you are right i used the os, i did not commit after deleting.

On Tue, Aug 9, 2011 at 11:00 AM, Giulio Troccoli
  wrote:

On 09/08/11 15:40, Adam Tong wrote:

Hi,

When i remove a file from my local copy, I cannot get it from the
repository using the command svn up.

Is there another way to get a recently deleted file? or there is
something wrong in my settings.

Thanks

Did you use the OS to delete the file or Subversion? Did you commit? If
you
can tell as exactly what you did we'd be in a better position to help


In that case the file should be back. What does svn status say?

And please, Reply-to-all so that the conversation stays on the mailing
list

Gulio


Well, is svn st says it's been deleted than you have use svn to delete the
file, or Subversion wouldn't know about it. So to restore it you can simply
use svn revert

Giulio



As far as I know no, there is no way to configure Subversion to know 
that. If you're using a Unix-like OS at work, make sure you don't have 
an alias, or maybe a local rm that it's actually a svn rm in disguise


Giulio

Re: Cannot get a file when deleted

[Adam Tong]

Thank you so much Giulio for your help.

On Tue, Aug 9, 2011 at 11:40 AM, Giulio Troccoli
 wrote:
>
>
> On 09/08/11 16:28, Adam Tong wrote:
>>
>> You are right i just tested when i do revert it is reverted and i can
>> see it in the file system.
>>
>> On the other hand, I am sure that i am doing "rm filename" and not svn
>> delete filename.
>>
>> Maybe there is a way to configure svn so that it considers rm as
>> equivalent to svn delete?
>>
>> Because this is happens in my job and does not in my laptop at home.
>>
>>
>> On Tue, Aug 9, 2011 at 11:20 AM, Giulio Troccoli
>>   wrote:
>>>
>>> On 09/08/11 16:18, Adam Tong wrote:

 svn st gives the that the file was deleted (D) when i do svn up it
 does not bring it. But when i did the first sugetion of copy -r 
 it worked

 sorry about forgeting to reply to all


 On Tue, Aug 9, 2011 at 11:03 AM, Giulio Troccoli
     wrote:
>
> On 09/08/11 16:02, Adam Tong wrote:
>>
>> you are right i used the os, i did not commit after deleting.
>>
>> On Tue, Aug 9, 2011 at 11:00 AM, Giulio Troccoli
>>       wrote:
>>>
>>> On 09/08/11 15:40, Adam Tong wrote:

 Hi,

 When i remove a file from my local copy, I cannot get it from the
 repository using the command svn up.

 Is there another way to get a recently deleted file? or there is
 something wrong in my settings.

 Thanks
>>>
>>> Did you use the OS to delete the file or Subversion? Did you commit?
>>> If
>>> you
>>> can tell as exactly what you did we'd be in a better position to help
>>>
> In that case the file should be back. What does svn status say?
>
> And please, Reply-to-all so that the conversation stays on the mailing
> list
>
> Gulio
>
>>> Well, is svn st says it's been deleted than you have use svn to delete
>>> the
>>> file, or Subversion wouldn't know about it. So to restore it you can
>>> simply
>>> use svn revert
>>>
>>> Giulio
>>>
>
> As far as I know no, there is no way to configure Subversion to know that.
> If you're using a Unix-like OS at work, make sure you don't have an alias,
> or maybe a local rm that it's actually a svn rm in disguise
>
> Giulio
>

Transmitting file data .svn: Commit failed

[Kathy Khaghani]

Hi,

I'm using svn, version 1.5.0 (r31699) on Linux Fedora Core release 4 OS,  when 
I trying committing a file I get this error message:

Sendingevents/fms/index.php
Transmitting file data .svn: Commit failed (details follow):
svn: MERGE of '/repos/sites/trunk/www/STEC/aboutstec/events/fms': Could not 
read status line: Secure connection truncated (https://webbuild)

I am using Openssh openssh-4.0p1-3 and
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so


I have done a lot of search, but have not found an answer to this.  Has anyone, 
seen this or know how to fix it?

Your help is greatly appreciated, since this is our development server and very 
important to get this resolved.

Best Regards,

Kathy Khaghani
Sr. Unix Admin
Office 949.476.1180 x8414 * Fax 949.851.2756

STEC, Inc. | The SSD CompanyTM
NASDAQ STEC * Web www.stec-inc.com

[cid:image002.png@01CC5679.ACF28BF0][cid:image004.png@01CC5679.ACF28BF0][cid:image006.png@01CC5679.ACF28BF0][cid:image008.png@01CC5679.ACF28BF0][cid:image010.png@01CC5679.ACF28BF0][cid:image012.png@01CC5679.ACF28BF0]


PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED

This electronic transmission, and any documents attached hereto, may contain 
confidential, proprietary and/or legally privileged information. The 
information is intended only for use by the recipient named above. If you 
received this electronic message in error, please notify the sender and delete 
the electronic message. Any disclosure, copying, distribution, or use of the 
contents of information received in error is strictly prohibited, and violators 
will be pursued legally.
<><><><><><>

mod_dav_svn configuration

[Ryan Blue]

Hello,

I'm trying to use mod_dav_svn to host repositories that are arranged in 
project directories and I can't get the configuration to work.  My 
projects look like this:


 /srv/svn/project1/repo1
 /srv/svn/project1/repo2
 /srv/svn/project2/repo1

I'm running into trouble configuring mod_dav_svn; all I can find in the 
documentation is to use SVNParentPath, but the path given must be the 
direct parent of SVN repositories.  I would have to supply 
/srv/svn/project1 and /srv/svn/project2 in separate Location directives 
to apache.  The problem that I'm running into is that these project 
directories are dynamically created and I need a way to configure all 
potential project directories without creating a separate Location 
directive for each and restarting apache.


Solutions I've tried:

#1. I tried to symlink /srv/svn/project1.repo1 to 
/srv/svn/project1/repo1 (or move the repo) and use /srv/svn as 
SVNParentPath.  While this solution works to serve the repositories, it 
changes the URL.  My other repositories are served with paths like 
/p/project1/repo1.git/ and I would like for SVN to follow the same 
model; it wouldn't be very nice to require users to remember that SVN is 
special and has a non-standard repository URL.


I've tried URL rewriting to fix the resulting URL problem, but the SVN 
client sends the URL it is using to the SVN server when it does a 
checkout (this is a REPORT request, with 
http://original-url/).  The SVN server responds 
with a 500 error: "Unusable URI: it does not refer to this repository" 
after getting most of the way through the checkout.  Viewing the 
repository in a browser seems to work fine, because the browser doesn't 
send the URL as data.  I *could* fix this by rewriting the request body, 
but that seems like a terrible idea to me.


#2. I tried to find an apache configuration trick that would allow me to 
set the SVNParentPath for all projects.  This concept is best demonstrated:



  DAV svn
  SVNParentPath /srv/svn/$1
  SVNListParentPath on


The problem with this, besides the fact that I'm not sure if \w would 
work, is that I don't know of a way that I can use the matched content 
in the SVNParentPath.  In fact, it seems that the SVNParentPath must be 
a static directory.  Another thing that would work is a "here" option 
for SVNParentPath/SVNPath, that would take the current directory and use 
it for the path:



  DAV svn
  SVNParentPath here
  SVNListParentPath on


If apache config magic like this exists, I haven't found it yet.  Does 
anyone on this list know a way to serve these repositories?  Is there a 
good way to configure apache and set SVNParentPath dynamically for each 
project directory like I've attempted in solution #2?  Is there a 
configuration setting to turn off the URL check I'm hitting in solution #1?


I'm also open to the idea of contributing a patch for mod_dav_svn to do 
this, if that is what is necessary.  It seems like a good solution would 
be to add a SVNSearchParentPath option that causes mod_dav_svn to check 
each directory in the path until it finds a valid repository, i.e., 
contains a 'format' file with a valid format code.


Thanks for the help,

rb

Re: Transmitting file data .svn: Commit failed

[Stefan Sperling]

On Tue, Aug 09, 2011 at 09:49:47AM -0700, Kathy Khaghani wrote:
> Hi,
> 
> I'm using svn, version 1.5.0 (r31699) on Linux Fedora Core release 4 OS,  
> when I trying committing a file I get this error message:
> 
> Sendingevents/fms/index.php
> Transmitting file data .svn: Commit failed (details follow):
> svn: MERGE of '/repos/sites/trunk/www/STEC/aboutstec/events/fms': Could not 
> read status line: Secure connection truncated (https://webbuild)
> 
> I am using Openssh openssh-4.0p1-3 and
> LoadModule dav_svn_module modules/mod_dav_svn.so
> LoadModule authz_svn_module   modules/mod_authz_svn.so
> 
> 
> I have done a lot of search, but have not found an answer to this.  Has 
> anyone, seen this or know how to fix it?
> 
> Your help is greatly appreciated, since this is our development server and 
> very important to get this resolved.
> 

The error means that the connection to the server was cut for some
reason.

Maybe someone restarted the server while your commit was in progress?

The only way to find out what really happened is checking the server log.

RE: Transmitting file data .svn: Commit failed

[Kathy Khaghani]

Stefan,

Thank you so much for your fast response! To give you a bit more info, this 
error has been happening with every commit on this repository, I am the only 
one who uses it, and I read someplace that I could be timing out so I have set: 
SSLSessionCacheTimeout  3600
And SVNPathAuthz off

Also my apache server log says:
[Fri Aug 05 13:19:12 2011] [notice] child pid 9127 exit signal Segmentation 
fault (11)

Which again I have not found much useful information about.


Regards,
Kathy

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: Tuesday, August 09, 2011 10:01 AM
To: Kathy Khaghani
Cc: 'users@subversion.apache.org'
Subject: Re: Transmitting file data .svn: Commit failed

On Tue, Aug 09, 2011 at 09:49:47AM -0700, Kathy Khaghani wrote:
> Hi,
> 
> I'm using svn, version 1.5.0 (r31699) on Linux Fedora Core release 4 OS,  
> when I trying committing a file I get this error message:
> 
> Sendingevents/fms/index.php
> Transmitting file data .svn: Commit failed (details follow):
> svn: MERGE of '/repos/sites/trunk/www/STEC/aboutstec/events/fms': Could not 
> read status line: Secure connection truncated (https://webbuild)
> 
> I am using Openssh openssh-4.0p1-3 and
> LoadModule dav_svn_module modules/mod_dav_svn.so
> LoadModule authz_svn_module   modules/mod_authz_svn.so
> 
> 
> I have done a lot of search, but have not found an answer to this.  Has 
> anyone, seen this or know how to fix it?
> 
> Your help is greatly appreciated, since this is our development server and 
> very important to get this resolved.
> 

The error means that the connection to the server was cut for some
reason.

Maybe someone restarted the server while your commit was in progress?

The only way to find out what really happened is checking the server log.

PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED

This electronic transmission, and any documents attached hereto, may contain 
confidential, proprietary and/or legally privileged information. The 
information is intended only for use by the recipient named above. If you 
received this electronic message in error, please notify the sender and delete 
the electronic message. Any disclosure, copying, distribution, or use of the 
contents of information received in error is strictly prohibited, and violators 
will be pursued legally.

RE: not storing diffs of binary files

[Jon Stafford]

Thanks everyone for the responses.  To check my understanding, and to give half 
a conclusion -

Every revision apart from the very initial revision of a file is stored as a 
delta against some previous version.  Subversion would typically probably use 
the least disk space *if* each revision was stored as a delta against the 
immediately preceding revision.  But that would be really slow for 
reconstructing the 1000th revision.  So instead, each revision is stored as a 
delta against a base of flip-rightmost-1.

This generally gives a balance between space used up and time to recreate any 
given revision of the file.

OK, how does all that sound so far?

Knowing this I was hoping I'd look again and understand what was going on with 
my repository with successive zips of my database data checked in.  Not quite...

I can see that the deltas aren't necessarily against the immediately preceding 
version - in fact with 15 revisions it's satisfying/reassuring to see them 
doing exactly as billed in the skip deltas document.

The bit I still can't reconcile is the difference in the delta size between 
xdelta standalone (small) and the delta stored by subversion (large - almost 
the size of the file itself sometimes).

I've checked in various versions of my database data zipped.  Some with a month 
of changes between each revision, some with the most trivial change possible 
between revisions.

For a trivial change: 
xdelta delta size = 300KB, subversion db\revs file size = 300KB

For a month of database edits:
xdelta delta size = 3 or 4MB, subversion db\revs file size = 50MB

Obviously for fair comparison I'm only picking on revisions where subversion 
did delta against the immediately preceding revision.

So does subversion (version 1.6.11) use an old, not quite so good, xdelta?  Or 
is it just that it applies xdelta after its already done some format 
manipulation on the file, which then makes it less delta-able?  Or something 
else...

Jon


-Original Message-
From: Andreas Krey [mailto:a.k...@gmx.de] 
Sent: 08 August 2011 13:44
To: Mark Phippard
Cc: Daniel Shahaf; Jon Stafford; users@subversion.apache.org
Subject: Re: not storing diffs of binary files

On Mon, 08 Aug 2011 16:28:42 +, Mark Phippard wrote:
...
> All revisions are "deltified" but some are deltified against an empty
> stream.  I do not know if the diagram is accurate, but revisions 1 and 2 of
> the file are both against the empty stream.

Revision 0 goes as a regular revision in that diagram, according to the text.
This way every rev but the first is deltified; would be stupid otherwise.
(And the first is deltified against the empty stream.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Transmitting file data .svn: Commit failed

[Stefan Sperling]

On Tue, Aug 09, 2011 at 10:10:32AM -0700, Kathy Khaghani wrote:
> Stefan,
> 
> Thank you so much for your fast response! To give you a bit more info, this 
> error has been happening with every commit on this repository, I am the only 
> one who uses it, and I read someplace that I could be timing out so I have 
> set: 
> SSLSessionCacheTimeout  3600
> And SVNPathAuthz off
> 
> Also my apache server log says:
> [Fri Aug 05 13:19:12 2011] [notice] child pid 9127 exit signal Segmentation 
> fault (11)
> 
> Which again I have not found much useful information about.

The segmentation fault message means the server is crashing.
The client connection gets dropped when the crash happens.

You were saying you're using version 1.5.0 on Linux Fedora release 4.
That is very old, so I assume your setup was working for quite some
time. You should try to pinpoint which change on the server caused
this problem. Something must have changed recently.

As an aside, I'd highly recommend to upgrade your server to
Subversion 1.6.17 as soon as possible. The 1.5.x release series
will stop being supported soon (when 1.7.0 is released).

Re: not storing diffs of binary files

[Mark Phippard]

On Tue, Aug 9, 2011 at 1:19 PM, Jon Stafford
wrote:

> Thanks everyone for the responses.  To check my understanding, and to give
> half a conclusion -
>
> Every revision apart from the very initial revision of a file is stored as
> a delta against some previous version.  Subversion would typically probably
> use the least disk space *if* each revision was stored as a delta against
> the immediately preceding revision.  But that would be really slow for
> reconstructing the 1000th revision.  So instead, each revision is stored as
> a delta against a base of flip-rightmost-1.
>
> This generally gives a balance between space used up and time to recreate
> any given revision of the file.
>
> OK, how does all that sound so far?
>
> Knowing this I was hoping I'd look again and understand what was going on
> with my repository with successive zips of my database data checked in.  Not
> quite...
>
> I can see that the deltas aren't necessarily against the immediately
> preceding version - in fact with 15 revisions it's satisfying/reassuring to
> see them doing exactly as billed in the skip deltas document.
>
> The bit I still can't reconcile is the difference in the delta size between
> xdelta standalone (small) and the delta stored by subversion (large - almost
> the size of the file itself sometimes).
>
> I've checked in various versions of my database data zipped.  Some with a
> month of changes between each revision, some with the most trivial change
> possible between revisions.
>
> For a trivial change:
> xdelta delta size = 300KB, subversion db\revs file size = 300KB
>
> For a month of database edits:
> xdelta delta size = 3 or 4MB, subversion db\revs file size = 50MB
>
> Obviously for fair comparison I'm only picking on revisions where
> subversion did delta against the immediately preceding revision.
>
> So does subversion (version 1.6.11) use an old, not quite so good, xdelta?
>  Or is it just that it applies xdelta after its already done some format
> manipulation on the file, which then makes it less delta-able?  Or something
> else...
>

I do not understand it enough to give a lot of details so let me point you
to an old thread on the list:

http://svn.haxx.se/dev/archive-2007-03/1277.shtml

The xdelta algorithm has a configurable window that determines the amount of
memory used.  The more memory you give it, the smaller the delta it can
often produce.  It is likely the xdelta binary you are using uses a larger
window than Subversion.

-- 
Thanks

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

best practice: accessing svn data without co

[Jan Ciesko (GMAIL)]

Dear SVN users

I would like to ask the following: is there a way to access svn data on 
the svn server without checking data out? I would need to create 
temporal tar'ed archive of a versioned directory that is then attached 
to a website. Both web- and svn-server are running on the same system.


Thanks a lot for help.
Best regards,
Jan.

Re: updates on subdirectories : revision not being pulled

[Mark Phippard]

On Tue, Aug 9, 2011 at 1:57 PM, Igor DEFAYE  wrote:


> We have a major problem on our Apache Subversion. When updating some
> revisions are not pulled down to the pc, regardless of which pc we use.
>
> This seems to happen only when updating from a sub-directory and not
> updating from root directory, but it might also happen from root dir, I’ve
> just haven’t seen it happen yet.
>
> 
>
> I don’t know if this is an already known issue, or if I need to submit a
> new one. So I hope someone can help me look rapidly over this.
>
> ** **
>
> Our server is up to date : 1.6.17 build 2190.74 . We administer the server
> via Collabnet Subversion Edge. We mostly use tortoise svn clients, they were
> updated but the problem is server side.
>
> ** **
>
> We have noticed the revisions that are not pulled down to the pcs also do
> not appear in the change log on the subdirectory, but does on higher
> directories. 
>
> ** **
>
> May be an example will make it clearer  :
>
> On root directory we see the change log for revision 20445, it concerns
> only one file : /SuiteFM_dot_Net/Bin/www/ope_RAPPORT/js/container.js
>
> Both Collabnet or tortoise show the same, so far so good.
>

Please do not mail dev@.  This is not a discussion about the development of
Subversion.

Based on your screenshots, I would suggest you look at revision 20453.  If
someone replaced the folder in that commit with an earlier version from its
history than everything in your screenshots makes perfect sense.  Basically
@ revision 20453, the folder was replaced, creating a new line of history
that does not include those other revisions.


-- 
Thanks

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

Re: best practice: accessing svn data without co

[Andreas Krey]

On Tue, 09 Aug 2011 20:27:53 +, Jan Ciesko (GMAIL) wrote:
> Dear SVN users
> 
> I would like to ask the following: is there a way to access svn data on 
> the svn server without checking data out?

'svn cat $URL' and 'svn ls $URL' come to mind.
But not easy to get a tree with those.

> I would need to create 
> temporal tar'ed archive of a versioned directory that is then attached 

What is 'temporal' in this context? Why isn't 'svn export & tar' an option?

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: best practice: accessing svn data without co

[Geoff Hoffman]

On Tue, Aug 9, 2011 at 11:27 AM, Jan Ciesko (GMAIL) wrote:

> Dear SVN users
>
> I would like to ask the following: is there a way to access svn data on the
> svn server without checking data out? I would need to create temporal tar'ed
> archive of a versioned directory that is then attached to a website. Both
> web- and svn-server are running on the same system.
>
> Thanks a lot for help.
> Best regards,
> Jan.
>


Jan,

Are you looking for svn export?

Re: best practice: accessing svn data without co

[David Weintraub]

Take a look at Sventon (http://sventon.org). It's a web-based
Subversion interface, and I believe it can be setup to allow users to
download folders as tarballs.

On Tue, Aug 9, 2011 at 2:27 PM, Jan Ciesko (GMAIL)  wrote:
> Dear SVN users
>
> I would like to ask the following: is there a way to access svn data on the
> svn server without checking data out? I would need to create temporal tar'ed
> archive of a versioned directory that is then attached to a website. Both
> web- and svn-server are running on the same system.
>
> Thanks a lot for help.
> Best regards,
> Jan.
>
>
>



-- 
David Weintraub
qazw...@gmail.com

Re: best practice: accessing svn data without co

[Les Mikesell]

Viewvc has an option to generate a tarball download for any path/revision.


On 8/9/2011 1:33 PM, David Weintraub wrote:

Take a look at Sventon (http://sventon.org). It's a web-based
Subversion interface, and I believe it can be setup to allow users to
download folders as tarballs.

On Tue, Aug 9, 2011 at 2:27 PM, Jan Ciesko (GMAIL)  wrote:

Dear SVN users

I would like to ask the following: is there a way to access svn data on the
svn server without checking data out? I would need to create temporal tar'ed
archive of a versioned directory that is then attached to a website. Both
web- and svn-server are running on the same system.

Thanks a lot for help.
Best regards,
Jan.

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Nico Kadel-Garcia]

On Mon, Aug 8, 2011 at 6:19 PM,   wrote:
> For a while I was downloading and running the development build of
> subversion 1.7.0.  At one revision of the code I started having an issue
> where svn would immediately segfault.  At that time I stopped using 1.7.0
> assuming the issue would be fixed before release.  Unfortunately I just
> downloaded the beta2 release of 1.7.0 and I’m having the same problem.
> Interestingly enough I can successfully build beta2 on one of our 32bit
> systems, but I can’t use that build on our 64 bit systems because it tries
> to link against the 32bit version of libmagic.

RHEL 4 is, frankly, way too old to support with new tools. It's
initial release was over six years, and far too many core libraries,
such as swig and sqlite and python, have not gotten updated to match
subversion requirements.

I'm trying to rebundle an SRPM for 1.6.17 for the RPMforge repository,
and no way am I burning the cycles to get it back to RHEL 4. The
1.7.0beta3 releases will compile well enough on RHEL 5, especially if
you build from an SRPM for 1.6.x first to get most of the dependencies
resolved.

RHEL 5, and Scientific Linux 5, have subversion-1.6.11 available from
the upstream vendor. Would that be enough for you?

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Mark Phippard]

On Tue, Aug 9, 2011 at 2:58 PM, Nico Kadel-Garcia  wrote:

> On Mon, Aug 8, 2011 at 6:19 PM,   wrote:
> > For a while I was downloading and running the development build of
> > subversion 1.7.0.  At one revision of the code I started having an issue
> > where svn would immediately segfault.  At that time I stopped using 1.7.0
> > assuming the issue would be fixed before release.  Unfortunately I just
> > downloaded the beta2 release of 1.7.0 and I’m having the same problem.
> > Interestingly enough I can successfully build beta2 on one of our 32bit
> > systems, but I can’t use that build on our 64 bit systems because it
> tries
> > to link against the 32bit version of libmagic.
>
> RHEL 4 is, frankly, way too old to support with new tools. It's
> initial release was over six years, and far too many core libraries,
> such as swig and sqlite and python, have not gotten updated to match
> subversion requirements.
>

Whether it is a good idea and whether it ought to work are really two
separate conversations.  1.7 was building fine on RHEL 4 and then stopped
working.  Is that a bug that should be fixed?  I think so.  It might be up
to Michael to track down what caused the breakage though.  Like I said, I
also saw this problem but I was able to move to RHEL 5. So I lacked
motivation to solve it on RHEL 4.  In my case, I build my own version of all
of the dependencies, the versions that come from Red Hat does not matter to
me.  Exception being gcc and libc etc.


-- 
Thanks

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

RE: not storing diffs of binary files

[Jon Stafford]

Thanks very much Mark.  That thread was very useful and it's great to 
understand what's actually going on here.

I've summarized all this in an answer back on stackoverflow:
http://stackoverflow.com/questions/6917505/inexplicable-svn-repository-size-increase-from-small-differences-to-big-files/7001562#7001562

Jon


From: Mark Phippard [mailto:markp...@gmail.com]
Sent: 09 August 2011 10:50
To: Jon Stafford
Cc: Andreas Krey; Daniel Shahaf; users@subversion.apache.org
Subject: Re: not storing diffs of binary files

On Tue, Aug 9, 2011 at 1:19 PM, Jon Stafford 
mailto:jon.staff...@complyserve.com>> wrote:
Thanks everyone for the responses.  To check my understanding, and to give half 
a conclusion -

Every revision apart from the very initial revision of a file is stored as a 
delta against some previous version.  Subversion would typically probably use 
the least disk space *if* each revision was stored as a delta against the 
immediately preceding revision.  But that would be really slow for 
reconstructing the 1000th revision.  So instead, each revision is stored as a 
delta against a base of flip-rightmost-1.

This generally gives a balance between space used up and time to recreate any 
given revision of the file.

OK, how does all that sound so far?

Knowing this I was hoping I'd look again and understand what was going on with 
my repository with successive zips of my database data checked in.  Not quite...

I can see that the deltas aren't necessarily against the immediately preceding 
version - in fact with 15 revisions it's satisfying/reassuring to see them 
doing exactly as billed in the skip deltas document.

The bit I still can't reconcile is the difference in the delta size between 
xdelta standalone (small) and the delta stored by subversion (large - almost 
the size of the file itself sometimes).

I've checked in various versions of my database data zipped.  Some with a month 
of changes between each revision, some with the most trivial change possible 
between revisions.

For a trivial change:
xdelta delta size = 300KB, subversion db\revs file size = 300KB

For a month of database edits:
xdelta delta size = 3 or 4MB, subversion db\revs file size = 50MB

Obviously for fair comparison I'm only picking on revisions where subversion 
did delta against the immediately preceding revision.

So does subversion (version 1.6.11) use an old, not quite so good, xdelta?  Or 
is it just that it applies xdelta after its already done some format 
manipulation on the file, which then makes it less delta-able?  Or something 
else...

I do not understand it enough to give a lot of details so let me point you to 
an old thread on the list:

http://svn.haxx.se/dev/archive-2007-03/1277.shtml

The xdelta algorithm has a configurable window that determines the amount of 
memory used.  The more memory you give it, the smaller the delta it can often 
produce.  It is likely the xdelta binary you are using uses a larger window 
than Subversion.

--
Thanks

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

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

Unfortunately, some of us don't have a choice what version of linux we have to 
run on.  I end up compiling almost all the dependencies for subversion myself.  
I guess I'll need to track down exactly what change in the development process 
started breaking things.  For now, we have a solution where I've compiled on 
32bit with support for libmagic manually removed.

As a side note, it would be nice to actually be able to add a 
--without-libmagic and have the configure script work without hacking.  The 
release notes even say libmagic is optional, but the way I see it currently, 
the only we the default configure won't use it is if your build machine doesn't 
have libmagic installed.

-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Sent: Tuesday, August 09, 2011 12:59 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit

On Mon, Aug 8, 2011 at 6:19 PM,   wrote:
> For a while I was downloading and running the development build of 
> subversion 1.7.0.  At one revision of the code I started having an 
> issue where svn would immediately segfault.  At that time I stopped 
> using 1.7.0 assuming the issue would be fixed before release.  
> Unfortunately I just downloaded the beta2 release of 1.7.0 and I'm having the 
> same problem.
> Interestingly enough I can successfully build beta2 on one of our 
> 32bit systems, but I can't use that build on our 64 bit systems 
> because it tries to link against the 32bit version of libmagic.

RHEL 4 is, frankly, way too old to support with new tools. It's initial release 
was over six years, and far too many core libraries, such as swig and sqlite 
and python, have not gotten updated to match subversion requirements.

I'm trying to rebundle an SRPM for 1.6.17 for the RPMforge repository, and no 
way am I burning the cycles to get it back to RHEL 4. The
1.7.0beta3 releases will compile well enough on RHEL 5, especially if you build 
from an SRPM for 1.6.x first to get most of the dependencies resolved.

RHEL 5, and Scientific Linux 5, have subversion-1.6.11 available from the 
upstream vendor. Would that be enough for you?

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Mark Phippard]

On Tue, Aug 9, 2011 at 3:24 PM,  wrote:

> Unfortunately, some of us don't have a choice what version of linux we have
> to run on.  I end up compiling almost all the dependencies for subversion
> myself.  I guess I'll need to track down exactly what change in the
> development process started breaking things.  For now, we have a solution
> where I've compiled on 32bit with support for libmagic manually removed.
>

Did you try building a 64-bit version with the same hack?  I would not
expect libmagic to be related to the crashing, but there is some
circumstantial evidence to say it is worth looking at.  Most notably, the
support for that feature was added very late in the dev cycle and you said
that RHEL 4 binaries from trunk were working for you until recently.


> As a side note, it would be nice to actually be able to add a
> --without-libmagic and have the configure script work without hacking.  The
> release notes even say libmagic is optional, but the way I see it currently,
> the only we the default configure won't use it is if your build machine
> doesn't have libmagic installed.
>

It should be possible to do this, so it is a bug.  I think I saw the
developers discussing this on IRC, so I suspect it will be fixed if it does
not work.



-- 
Thanks

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

1.7 corrupts WC when reverting add of changelist member

[Stein Somers]

When you revert an addition in your working copy, and the item appeared in a 
changelist, the working copy becomes corrupt and you can't ever use the filename 
again. I built a maintainer mode version from /branches/1.7.x@1155504 which 
balks (after a boring stack trace):


svn: E155016: Corrupt data for './sandbox/wc/x'

at the end of this test script:

#!/bin/bash
alias svn=$PWD/../subversion/subversion/svn/svn
alias svnadmin=$PWD/../subversion/subversion/svnadmin/svnadmin

rm -rf sandbox
mkdir sandbox
set -eux
cd sandbox
svnadmin create repo1
url=file:///$PWD/repo1/trunk
svn mkdir -m boot "$url"
svn co "$url" wc
cd wc
# Need at least one versioned file, otherwise there's no problem
echo first >first
svn add first
svn commit -m blah
svn up
# Try to add a file x, in an uncertain state of mind
echo x >x
svn add x
svn cl c x
svn revert x
svn add x

--
Stein

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

Ok, I've tracked down which revision caused the problem.  It happened in rev 
1104160.  Stefan2 made a change to utf.c to speed up UTF8 conversion.  Ever 
since this change went in I am seeing subversion crash when I compile on 64bit 
el4.

Just for kicks and giggles I updated to the HEAD revision of 
http://svn.apache.org/repos/asf/subversion/trunk.  Did a reverse merge on rev 
1104160, cleaned up the conflicts and built it and viola!  No more crashing 
when built on 64bit el4.

-Mike

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Mark Phippard]

On Tue, Aug 9, 2011 at 4:49 PM,  wrote:

> ** **
>
> Ok, I’ve tracked down which revision caused the problem.  It happened in
> rev 1104160.  Stefan2 made a change to utf.c to speed up UTF8 conversion.
> Ever since this change went in I am seeing subversion crash when I compile
> on 64bit el4.
>
> ** **
>
> Just for kicks and giggles I updated to the HEAD revision of
> http://svn.apache.org/repos/asf/subversion/trunk.  Did a reverse merge on
> rev 1104160, cleaned up the conflicts and built it and viola!  No more
> crashing when built on 64bit el4.
>

Thanks.  Moving the thread to dev@

Can someone look at this and possibly fix it?

If you are not on users@, and to summarize this thread.  SVN builds fine on
RHEL 4 64-bit but crashes immediately on any command, even svn help.  I saw
the same problem with our builds.

-- 
Thanks

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

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

I am attaching a patch file which I used to change utf.c in the head revision 
to get things to play nice with el4 64bit.  "make check" does come back clean 
with this version.

-Mike

P.S. why isn't "make check" structured so that the -j option to make would 
work.  It would be nice to use multiple threads to speed up the run.

From: Mark Phippard [mailto:markp...@gmail.com]
Sent: Tuesday, August 09, 2011 2:56 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit


On Tue, Aug 9, 2011 at 4:49 PM, 
mailto:michael_rytt...@agilent.com>> wrote:

Ok, I've tracked down which revision caused the problem.  It happened in rev 
1104160.  Stefan2 made a change to utf.c to speed up UTF8 conversion.  Ever 
since this change went in I am seeing subversion crash when I compile on 64bit 
el4.

Just for kicks and giggles I updated to the HEAD revision of 
http://svn.apache.org/repos/asf/subversion/trunk.  Did a reverse merge on rev 
1104160, cleaned up the conflicts and built it and viola!  No more crashing 
when built on 64bit el4.

Thanks.  Moving the thread to dev@

Can someone look at this and possibly fix it?

If you are not on users@, and to summarize this thread.  SVN builds fine on 
RHEL 4 64-bit but crashes immediately on any command, even svn help.  I saw the 
same problem with our builds.

--
Thanks

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

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

And of course I forget to actually attach the file.

From: Mark Phippard [mailto:markp...@gmail.com]
Sent: Tuesday, August 09, 2011 2:56 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit


On Tue, Aug 9, 2011 at 4:49 PM, 
mailto:michael_rytt...@agilent.com>> wrote:

Ok, I've tracked down which revision caused the problem.  It happened in rev 
1104160.  Stefan2 made a change to utf.c to speed up UTF8 conversion.  Ever 
since this change went in I am seeing subversion crash when I compile on 64bit 
el4.

Just for kicks and giggles I updated to the HEAD revision of 
http://svn.apache.org/repos/asf/subversion/trunk.  Did a reverse merge on rev 
1104160, cleaned up the conflicts and built it and viola!  No more crashing 
when built on 64bit el4.

Thanks.  Moving the thread to dev@

Can someone look at this and possibly fix it?

If you are not on users@, and to summarize this thread.  SVN builds fine on 
RHEL 4 64-bit but crashes immediately on any command, even svn help.  I saw the 
same problem with our builds.

--
Thanks

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


patch
Description: patch

Re: 1.7 corrupts WC when reverting add of changelist member

[Stefan Sperling]

On Tue, Aug 09, 2011 at 09:53:37PM +0200, Stein Somers wrote:
> When you revert an addition in your working copy, and the item
> appeared in a changelist, the working copy becomes corrupt and you
> can't ever use the filename again. I built a maintainer mode version
> from /branches/1.7.x@1155504 which balks (after a boring stack
> trace):
> 
>   svn: E155016: Corrupt data for './sandbox/wc/x'
> 
> at the end of this test script:

I can reproduce this on trunk.
Can you please file an issue? Thanks!

> 
> #!/bin/bash
> alias svn=$PWD/../subversion/subversion/svn/svn
> alias svnadmin=$PWD/../subversion/subversion/svnadmin/svnadmin
> 
> rm -rf sandbox
> mkdir sandbox
> set -eux
> cd sandbox
> svnadmin create repo1
> url=file:///$PWD/repo1/trunk
> svn mkdir -m boot "$url"
> svn co "$url" wc
> cd wc
> # Need at least one versioned file, otherwise there's no problem
> echo first >first
> svn add first
> svn commit -m blah
> svn up
> # Try to add a file x, in an uncertain state of mind
> echo x >x
> svn add x
> svn cl c x
> svn revert x
> svn add x
> 
> -- 
> Stein

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Hyrum K Wright]

On Tue, Aug 9, 2011 at 4:02 PM,   wrote:
>
> P.S. why isn’t “make check” structured so that the –j option to make would
> work.  It would be nice to use multiple threads to speed up the run.

The testsuite itself is internally parallelized.  I don't remember
what the magic options are to enable it, or if it is on by default,
but using -j for make check won't help.

(The reason we parallelize outside of 'make' is that we often run the
tests outside of 'make', and can take advantage of the parallelism in
those scenarios.)

-Hyrum

-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

RE: Transmitting file data .svn: Commit failed

[Kathy Khaghani]

Thanks again Stefan,

Sure enough every time I do a commit one of httpd daemon's get killed! I might 
have to upgrade afterall.

Regards,
Kathy

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: Tuesday, August 09, 2011 10:29 AM
To: Kathy Khaghani
Cc: 'users@subversion.apache.org'
Subject: Re: Transmitting file data .svn: Commit failed

On Tue, Aug 09, 2011 at 10:10:32AM -0700, Kathy Khaghani wrote:
> Stefan,
> 
> Thank you so much for your fast response! To give you a bit more info, this 
> error has been happening with every commit on this repository, I am the only 
> one who uses it, and I read someplace that I could be timing out so I have 
> set: 
> SSLSessionCacheTimeout  3600
> And SVNPathAuthz off
> 
> Also my apache server log says:
> [Fri Aug 05 13:19:12 2011] [notice] child pid 9127 exit signal Segmentation 
> fault (11)
> 
> Which again I have not found much useful information about.

The segmentation fault message means the server is crashing.
The client connection gets dropped when the crash happens.

You were saying you're using version 1.5.0 on Linux Fedora release 4.
That is very old, so I assume your setup was working for quite some
time. You should try to pinpoint which change on the server caused
this problem. Something must have changed recently.

As an aside, I'd highly recommend to upgrade your server to
Subversion 1.6.17 as soon as possible. The 1.5.x release series
will stop being supported soon (when 1.7.0 is released).

PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED

This electronic transmission, and any documents attached hereto, may contain 
confidential, proprietary and/or legally privileged information. The 
information is intended only for use by the recipient named above. If you 
received this electronic message in error, please notify the sender and delete 
the electronic message. Any disclosure, copying, distribution, or use of the 
contents of information received in error is strictly prohibited, and violators 
will be pursued legally.

How to solve svnadmin load "File already exists" error?

[Dennis Jones]

Hi,

I used rsvndump to dump a remote repository (because the server is running 
an old version of SVN from before support for 'replay' was added).  Now I am 
trying to load the dump file into my local repository (VisualSVN 2.1.9) and 
I'm getting the following error:


 * adding path : trunk/SomePath/SomeFile.zip ...svnadmin: File already 
exists: filesystem 'E:\Repositories\Archive\db', transaction '3186-2gi', 
path 'trunk/SomePath/SomeFile.zip'


Interestingly, it looks like it fails at revision 3186, but a glance at the 
output shows:

--- Committed revision 3186 >>>

<<< Started new transaction, based on original revision 3187

So why is the transaction for 3186 still there?

This is my second attempt at doing this, and I got the same error (in the 
same place) the first time.  The dump file is almost 5GB in size and the 
dump takes about 3 days to complete, so I'm not keen on doing it again, and 
I doubt it will help anyway.

Of course, I started with an empty repository on the local server, so it's 
not like it already had data in it.  So how can I get around this?

Dennis 

Re: not storing diffs of binary files

[Ryan Schmidt]

On Aug 9, 2011, at 12:19, Jon Stafford wrote:

> To check my understanding, and to give half a conclusion -
> 
> Every revision apart from the very initial revision of a file is stored as a 
> delta against some previous version.

I think even the initial revision of a file is stored as a delta -- against the 
empty revision 0.


> I've checked in various versions of my database data zipped.  Some with a 
> month of changes between each revision, some with the most trivial change 
> possible between revisions.

Consider testing again with your data not zipped -- just check in the text file 
of the data. This might allow Subversion to compress it better and/or make more 
reasonable deltas.

Re: mod_dav_svn configuration

[Ryan Schmidt]

On Aug 9, 2011, at 11:59, Ryan Blue wrote:

> I'm trying to use mod_dav_svn to host repositories that are arranged in 
> project directories and I can't get the configuration to work.  My projects 
> look like this:
> 
> /srv/svn/project1/repo1
> /srv/svn/project1/repo2
> /srv/svn/project2/repo1
> 
> I'm running into trouble configuring mod_dav_svn; all I can find in the 
> documentation is to use SVNParentPath, but the path given must be the direct 
> parent of SVN repositories.  I would have to supply /srv/svn/project1 and 
> /srv/svn/project2 in separate Location directives to apache.

[snip]

You've got it, basically. There isn't a way to configure SVNParentPath to do 
what you want, and Subversion doesn't play nicely with Apache redirects, so I 
recommend you conform your repository layout to SVNParentPath's requirements: a 
single directory containing all repositories. You could use a naming scheme to 
group repositories if desired, e.g.:

/srv/svn/project1_repo1
/srv/svn/project1_repo2
/srv/svn/project2_repo1


> I'm also open to the idea of contributing a patch for mod_dav_svn to do this, 
> if that is what is necessary.  It seems like a good solution would be to add 
> a SVNSearchParentPath option that causes mod_dav_svn to check each directory 
> in the path until it finds a valid repository, i.e., contains a 'format' file 
> with a valid format code.

I'm sure patches to improve SVNParentPath would be welcome. Is a new config 
option necessary? It seems ok to me if SVNParentPath would always be able to 
look into subdirectories.

Check trunk first; I recall something was changed about SVNParentPath there 
already but I don't remember exactly what.

Re: mod_dav_svn configuration

[Daniel Shahaf]

Ryan Schmidt wrote on Tue, Aug 09, 2011 at 20:07:39 -0500:
> On Aug 9, 2011, at 11:59, Ryan Blue wrote:
> 
> > I'm trying to use mod_dav_svn to host repositories that are arranged in 
> > project directories and I can't get the configuration to work.  My projects 
> > look like this:
> > 
> > /srv/svn/project1/repo1
> > /srv/svn/project1/repo2
> > /srv/svn/project2/repo1
> > 
> > I'm running into trouble configuring mod_dav_svn; all I can find in the 
> > documentation is to use SVNParentPath, but the path given must be the 
> > direct parent of SVN repositories.  I would have to supply 
> > /srv/svn/project1 and /srv/svn/project2 in separate Location directives to 
> > apache.
> 
> [snip]
> 
> You've got it, basically. There isn't a way to configure SVNParentPath
> to do what you want, and Subversion doesn't play nicely with Apache
> redirects, so I recommend you conform your repository layout to

http://subversion.apache.org/docs/release-notes/1.7#http-redirects

(the response codes were added to that section three minutes ago)

Re: mod_dav_svn configuration

[Matthew Beals]

Another option is to use mod_perl to build the individual blocks for each 
project using some logic. You could have it grab a list of project dies with ls 
(if they are in the same parent dir), or use a flat file or SQL database. The 
drawback is that you have to reload Apache for changes to take effect.


Matt

Daniel Shahaf  wrote:

Ryan Schmidt wrote on Tue, Aug 09, 2011 at 20:07:39 -0500:
> On Aug 9, 2011, at 11:59, Ryan Blue wrote:
> 
> > I'm trying to use mod_dav_svn to host repositories that are arranged in 
> > project directories and I can't get the configuration to work. My projects 
> > look like this:
> > 
> > /srv/svn/project1/repo1
> > /srv/svn/project1/repo2
> > /srv/svn/project2/repo1
> > 
> > I'm running into trouble configuring mod_dav_svn; all I can find in the 
> > documentation is to use SVNParentPath, but the path given must be the 
> > direct parent of SVN repositories. I would have to supply /srv/svn/project1 
> > and /srv/svn/project2 in separate Location directives to apache.
> 
> [snip]
> 
> You've got it, basically. There isn't a way to configure SVNParentPath
> to do what you want, and Subversion doesn't play nicely with Apache
> redirects, so I recommend you conform your repository layout to

http://subversion.apache.org/docs/release-notes/1.7#http-redirects

(the response codes were added to that section three minutes ago)

Help Needed regarding svn master-slave configuration

[Sharma, Gaurav]

Hi All,

I have a task in hand to setup a master-slave svn repository configuration so 
that master will synchronize its repositories with slave. I searched a lot on 
web and found many links telling about how to set it up. Following those links 
I started using "svnsync" for this purpose. But some how after spending many 
days I am not able it to work as desired. Both master and slave are on ubuntu 
10.xx. I am trying to set it up using HTTPS

I have two objectives for this setup-

1-   End user should be able to perform both check-out and check-in to the 
slave repository.
2-   Master should synchronize all its repository with slave

>From the very start I have not able to perform commit on the slave. I got 
>different errors time to time and I am really got tired of these errors.
If I commit on the master then master itself synchronizes with the slave but 
sometime even this part doesn't work.

Different configuration files are as follows:

On Master

/etc/apache2/mods-available/dav_svn.conf


  DAV svn
  SVNParentPath /home/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user


post-commit
/usr/bin/svnsync sync --username mirrorsync --password 123 --non-interactive 
http://slave-ip/svn-proxy-sync/mirror-repo

post-revprop-change
/usr/bin/svnsync copy-revprops --username mirrorsync --password 123 
http://slave-ip/svn-proxy-sync/mirror-repo $REV

On Slave

/etc/apache2/mods-available/dav_svn.conf


  DAV svn
  SVNParentPath /home/svn
  SVNMasterURI http://master-ip/svn/master-repo
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user



  DAV svn
  SVNParentPath /home/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user


start-commit

if [ "$USER" = "mirrorsync" ];
  then exit 0;
fi
echo "Only the mirrorsync user may commit new revisions" >&2 exit 1

pre-revprop-change

if [ "$USER" = "mirrorsync" ];
  then exit 0;
fi
echo "Only the mirrorsync user may change revision properties" >&2 exit 1

All kind of module (mod_dav, mod_dav_svn, proxy, proxy_http, ssl) are loaded. I 
don't have any past experience of working with svn or apache.

I WOULD REALLY APPRICIATE IF SOMEONE CAN HELP ME and tell me what the exact 
steps are to setup this configuration

Thanks
Gaurav

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.

Help Needed regarding svn master-slave configuration--resending i think its not delivered

[Sharma, Gaurav]

Hi All,

I have a task in hand to setup a master-slave svn repository configuration so 
that master will synchronize its repositories with slave. I searched a lot on 
web and found many links telling about how to set it up. Following those links 
I started using "svnsync" for this purpose. But some how after spending many 
days I am not able it to work as desired. Both master and slave are on ubuntu 
10.xx. I am trying to set it up using HTTPS

I have two objectives for this setup-

1-   End user should be able to perform both check-out and check-in to the 
slave repository.
2-   Master should synchronize all its repository with slave

>From the very start I have not able to perform commit on the slave. I got 
>different errors time to time and I am really got tired of these errors.
If I commit on the master then master itself synchronizes with the slave but 
sometime even this part doesn't work.

Different configuration files are as follows:

On Master

/etc/apache2/mods-available/dav_svn.conf


  DAV svn
  SVNParentPath /home/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user


post-commit
/usr/bin/svnsync sync --username mirrorsync --password 123 --non-interactive 
http://slave-ip/svn-proxy-sync/mirror-repo

post-revprop-change
/usr/bin/svnsync copy-revprops --username mirrorsync --password 123 
http://slave-ip/svn-proxy-sync/mirror-repo $REV

On Slave

/etc/apache2/mods-available/dav_svn.conf


  DAV svn
  SVNParentPath /home/svn
  SVNMasterURI http://master-ip/svn/master-repo
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user



  DAV svn
  SVNParentPath /home/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user


start-commit

if [ "$USER" = "mirrorsync" ];
  then exit 0;
fi
echo "Only the mirrorsync user may commit new revisions" >&2 exit 1

pre-revprop-change

if [ "$USER" = "mirrorsync" ];
  then exit 0;
fi
echo "Only the mirrorsync user may change revision properties" >&2 exit 1

All kind of module (mod_dav, mod_dav_svn, proxy, proxy_http, ssl) are loaded. I 
don't have any past experience of working with svn or apache.

I WOULD REALLY APPRICIATE IF SOMEONE CAN HELP ME and tell me what the exact 
steps are to setup this configuration

Thanks
Gaurav

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.