How can I retrieve the version of subversion itself?

[alibeck]

Hello list,

how can I obtain a version information about an installed subversion
client and server?

Cheers

Alexander

Re: Size of SVN Transaction vs Actual commit size

[B Smith-Mannschott]

On Fri, May 7, 2010 at 06:48, Ravi Roy  wrote:
>
> On Thu, May 6, 2010 at 3:37 PM, Ravi Roy  wrote:
>>
>> Hi
>>
>> General question about Transaction size versus actual file commit size. I
>> am getting strange results when I am trying to commit 1.28 file and
>> transaction size I am getting is 5538 bytes. Does somebody knows the mystery
>> ?
>
>
>    Sorry, Realised a mistake, please read 1.28 MB file.
>>
>>
>> I expect transaction size to be the same as actual commit size ? or some
>> compression in between ?
>>
>> Can somebody throw some light on this please?

This question is both confused and confusing. You'll have more success
if you use established subversion terminology correctly and avoid
making up your own terminology without defining it.

(I know it's a bit of a chicken-and-the-egg problem for a beginner.
See: http://svnbook.red-bean.com/en/1.5/index.html)

My guess: Subversion is working as designed and storing only the
compressed difference between the newest version of your 1.28 MB file
and some previous version of the same file. But, really, I can only
guess:

- Is the "1.28 MB file" a new to the repository, or did you commit
changes to an existing 1.28 MB file?

- What is this "transaction size" of which you speak? The size of a
file like $REPO/db/revs/12/12345?
- Why wouldn't you say "revision" in this case?
- Or are you really using a hook script to to peek at the actual
transaction during the commit before it becomes a revision?

- What is this "actual commit size" of which you speak?

- I assume you can successfully retrieve the "1.28 MB" file from the
repository. If so, the information must be there somewhere even if you
can't quite explain it to yourself.

- On that last point: http://svnbook.red-bean.com/en/1.5/index.html will help.

// Ben


>> Thanks
>>
>> -RR
>>
>>
>

RE: How can I retrieve the version of subversion itself?

[Giulio Troccoli]

>


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447

-Original Message-


> From: alibeck [mailto:alexander.beck-rat...@aei.mpg.de]
> Sent: 07 May 2010 08:14
> To: users@subversion.apache.org
> Subject: How can I retrieve the version of subversion itself?
>
> Hello list,
>
> how can I obtain a version information about an installed
> subversion client and server?
>

svn --version

G

svn update on a tag question

[David Aldrich]

Hi

One of our users asked me a question this morning that revealed that I don't 
fully understand revision numbering in svn. So I would like to ask for 
explanation please.


With the trunk at revision n, he created a tag using svn copy -r HEAD.  So I 
guess the tag was at then at revision n+1.

He then committed some changes to the trunk and realised that he wanted those 
changes to be reflected in the tag also. The trunk was then at, say revision 
n+2. He did the following in his tag folder in the working directory:

svn up -r n+2 --force

It seems that the tag was then at revision n+2, but the tag did not contain the 
files committed at n+2.

I realise this reflects some muddled thinking about how svn works. Please can 
someone explain why the tag did not inherit the latest changes?  (I guess a 
merge would be appropriate, but why exactly did the update not have the 
intended effect).

Best regards

David

RE: svn update on a tag question

[Giulio Troccoli]

>


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447

-Original Message-


> From: David Aldrich [mailto:david.aldr...@eu.nec.com]
> Sent: 07 May 2010 10:15
> To: users@subversion.apache.org
> Subject: svn update on a tag question
>
> Hi
>
> One of our users asked me a question this morning that
> revealed that I don't fully understand revision numbering in
> svn. So I would like to ask for explanation please.
>
>
> With the trunk at revision n, he created a tag using svn copy
> -r HEAD.  So I guess the tag was at then at revision n+1.
>
> He then committed some changes to the trunk and realised that
> he wanted those changes to be reflected in the tag also. The
> trunk was then at, say revision n+2. He did the following in
> his tag folder in the working directory:
>
> svn up -r n+2 --force
>
> It seems that the tag was then at revision n+2, but the tag
> did not contain the files committed at n+2.
>
> I realise this reflects some muddled thinking about how svn
> works. Please can someone explain why the tag did not inherit
> the latest changes?  (I guess a merge would be appropriate,
> but why exactly did the update not have the intended effect).

When you use the update command you simply bring down the changes done into 
that directory. If you specify a revision you bring down the changes upt to 
that revision.

In your case there were no changes done in the tag after th copy, so nothing 
changed in the tag. Even if you say -r n+2 that is the revision in the tag not 
in trunk. Because you haven't merged the changes from trunk, revision n+2 is 
the same as revision n for what the tag is concerned.

You need to merge first and then update.

Having said all that, you shouldn't change a tag. Tags are supposed to be 
read-only. Nothing in Subversion will stop you doing that, tag is just another 
directory, but it's not how tags are usually used.

G
Well, the update command brings down the changes done in the tag. If you 
specify a revision then the tag

RE: svn update on a tag question

[David Aldrich]

Hi Giulio

> When you use the update command you simply bring down the changes done
> into that directory. If you specify a revision you bring down the changes
> upt to that revision.

Thanks. I think that is the crucial point, that the update works on the 
directory in question. Tags had no changes and so had nothing to update.

> Having said all that, you shouldn't change a tag. Tags are supposed to be
> read-only. Nothing in Subversion will stop you doing that, tag is just
> another directory, but it's not how tags are usually used.

Yes, I understand, thanks.

David

generic linux binaries

[Arpad Ilia]

Hi!

Is there somewhere a generic linux binary distribution of subversion? One that 
just needs to be unpacked and needs no root privileges on a debian system.

Thanks for reading!

iarpad


signature.asc
Description: This is a digitally signed message part.

Re: Size of SVN Transaction vs Actual commit size

[Ravi Roy]

>  >> Can somebody throw some light on this please?
>
> This question is both confused and confusing. You'll have more success
> if you use established subversion terminology correctly and avoid
> making up your own terminology without defining it.
>
> (I know it's a bit of a chicken-and-the-egg problem for a beginner.
> See: http://svnbook.red-bean.com/en/1.5/index.html)
>
> My guess: Subversion is working as designed and storing only the
> compressed difference between the newest version of your 1.28 MB file
> and some previous version of the same file. But, really, I can only
> guess:
>
> Right, this is what I understand.


> - Is the "1.28 MB file" a new to the repository, or did you commit
> changes to an existing 1.28 MB file?
>

My 1.28 MB file is new to repository.

>
> - What is this "transaction size" of which you speak? The size of a
> file like $REPO/db/revs/12/12345?
>

I am computing transaction size and assume that it should be the same as
original file being committed (i.e.1.28 MB)


> - Why wouldn't you say "revision" in this case?
> - Or are you really using a hook script to to peek at the actual
> transaction during the commit before it becomes a revision?
>
>
Yes, I am computing transaction size under $REPOS/db/transactions/*blahblah*

 *blahblah* get created under transactions folder as soon as I try commit
and there itself its size is being computed.

REPOS="$1"
TXN="$2"
disk_usage=/usr/bin/du
ACTUAL_TRANSACTION_FOLDER=`ls $REPOS/db/transactions/`
TXN_SIZE=`$disk_usage -b $REPOS/db/transactions/$TXN.txn | cut -f1`
echo Transaction size  is $TXN_SIZE. >&2
sleep 100
exit 1
--


> - What is this "actual commit size" of which you speak?
>

 Actual commit size is 1.28 MB and this script gives me 5528 bytes.

 Something wrong with script or there is compression involved or what ?


>
> - I assume you can successfully retrieve the "1.28 MB" file from the
> repository. If so, the information must be there somewhere even if you
> can't quite explain it to yourself.
>
> - On that last point: http://svnbook.red-bean.com/en/1.5/index.html will
> help.
>
>
> Thanks

-RR

Re: Size of SVN Transaction vs Actual commit size

[Olivier Sannier]

Ravi Roy wrote:

Actual commit size is 1.28 MB and this script gives me 5528 bytes.
 Something wrong with script or there is compression involved or what ?

Well, reading the book could have told you that this is expected:

http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deltas 

Re: Size of SVN Transaction vs Actual commit size

[Ravi Roy]

On Fri, May 7, 2010 at 3:33 PM, Olivier Sannier  wrote:

> Ravi Roy wrote:
>
>> Actual commit size is 1.28 MB and this script gives me 5528 bytes.
>>  Something wrong with script or there is compression involved or what ?
>>
> Well, reading the book could have told you that this is expected:
>
>
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deltas
>


Thanks Olivier; but this is just abstract view; I want to compute the
transaction size based on some predefined value (say 5 MB) and allow commit
to the repository if transaction size (in case new file commit) is less than
or equal to this size.

Any idea you have ?

Thanks!

-RR

Re: Size of SVN Transaction vs Actual commit size

[Andy Levy]

On Fri, May 7, 2010 at 06:26, Ravi Roy  wrote:
>
>
> On Fri, May 7, 2010 at 3:33 PM, Olivier Sannier  wrote:
>>
>> Ravi Roy wrote:
>>>
>>> Actual commit size is 1.28 MB and this script gives me 5528 bytes.
>>>  Something wrong with script or there is compression involved or what ?
>>
>> Well, reading the book could have told you that this is expected:
>>
>>
>> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deltas
>
>
>
> Thanks Olivier; but this is just abstract view; I want to compute the
> transaction size based on some predefined value (say 5 MB) and allow commit
> to the repository if transaction size (in case new file commit) is less than
> or equal to this size.
>
> Any idea you have ?

You can't know how large the actual transaction file (assuming you're
using FSFS) will be in the repository until the transaction has been
committed.

There is compression done in the repository, in addition to other
tricks used to reduce space. The "abstract view" you were referred to
is important to understanding how Subversion stores things, so please
don't dismiss it.

What happens if you have a legitimate case for storing something
larger than your arbitrary size limit in the future?

Re: Size of SVN Transaction vs Actual commit size

[Daniel Becroft]

On Fri, May 7, 2010 at 8:26 PM, Ravi Roy  wrote:
>
>
> On Fri, May 7, 2010 at 3:33 PM, Olivier Sannier  wrote:
>>
>> Ravi Roy wrote:
>>>
>>> Actual commit size is 1.28 MB and this script gives me 5528 bytes.
>>>  Something wrong with script or there is compression involved or what ?
>>
>> Well, reading the book could have told you that this is expected:
>>
>>
>> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deltas
>
>
>
> Thanks Olivier; but this is just abstract view; I want to compute the
> transaction size based on some predefined value (say 5 MB) and allow commit
> to the repository if transaction size (in case new file commit) is less than
> or equal to this size.

Have a look into 'svnlook changed' and 'svnlook cat' commands.

Cheers,
Daniel B.

Re: Size of SVN Transaction vs Actual commit size

[Daniel Shahaf]

Ravi Roy wrote on Fri, 7 May 2010 at 15:56 +0530:
> I want to compute the transaction size based on some predefined value
> (say 5 MB)

Most probably, you're interested in the size of something *created*
by the transaction --- not in the physical size of the on-disk
representation of the transaction itself.  The transaction isn't
a long-lived repository object.

> and allow commit to the repository if transaction size (in
> case new file commit) is less than or equal to this size.
> 
> Any idea you have ?
> 
> Thanks!
> 
> -RR
> 

Re: Size of SVN Transaction vs Actual commit size

[Ravi Roy]

>
>
> > Thanks Olivier; but this is just abstract view; I want to compute the
> > transaction size based on some predefined value (say 5 MB) and
> allow commit
> > to the repository if transaction size (in case new file commit) is less
> than
> > or equal to this size.
> >
> > Any idea you have ?
>
> You can't know how large the actual transaction file (assuming you're
> using FSFS) will be in the repository until the transaction has been
> committed.
>
> There is compression done in the repository, in addition to other
> tricks used to reduce space. The "abstract view" you were referred to
> is important to understanding how Subversion stores things, so please
> don't dismiss it.
>
> What happens if you have a legitimate case for storing something
> larger than your arbitrary size limit in the future?
>

That can be taken as special case; based on users to allow disallow bigger
size commits I believe.

  No, I do not dismiss it,  it is helpful to understand the curcuitary and
how it works. :-) I wonder how people allow / disallow
  bigger  file commits to repository.

Yes I am using FSFS.

Thanks.
-RR

Re: Cherry-picking merges

[Stein Somers]

bad idea, and should be discouraged. A revision that contains
svn:mergeinfo changes should only contain the file and structure

> changes logically equivalent to the revisions that have been merged.

Sure, but back to Joël's question: that still does not mean SVN can 
assume this "merge changset" never needs to be merged back and you 
shouldn't have to cherry-pick around it.


Let's say we have source code or scripts in our repository. r10 changes 
a parameter to a function and adapts all callers. You merge r10 into a 
branch, but earlier in the branch you had added another call to the 
function. You need to fix the call before the merge is logically 
complete. You could still commit the "raw" merge first and the logical 
completion of the merge as a second changeset. In fact, that's what you 
would have to do to allow pristine cherry-picking from your branch back 
to the trunk.


So let's make it a little tougher: both branches have changed a 
parameter of the same function. Merge conflicts all over. You want all 
the help you can get to resolve those conflicts. So you call on your 
compiler, test suite, whatever. It's next to impossible to separate this 
merge into a "raw" merge and changes due to interference of the merge 
and earlier changes in the branch.



--
Stein

Re: Size of SVN Transaction vs Actual commit size

[Daniel Shahaf]

Daniel Becroft wrote on Fri, 7 May 2010 at 20:48 +1000:
> Have a look into 'svnlook changed' and 'svnlook cat' commands.

Subversion 1.7 will also have an 'svnlook filesize' subcommand.

Re: Cannot reintegrate feature branch

[Stefan Sperling]

On Fri, May 07, 2010 at 11:35:16AM +0800, Jean Seurin wrote:
> Hi Stefan,
> 
> unfortunately even with a fresh branch check out, it would not pick
> up the missing changes, that is the problem.

Can you try to find out why it would merge the remaining changes?

I don't think anyone can help you debug this remotely without
knowing what your mergeinfo really looks like.
Maybe you can pin-point the problem yourself by looking at
mergeinfo? Using commands like svn mergeinfo, and if necessary
looking at mergeinfo properties directly should provide clues.

Stefan

Re: Tree conflicts on merging into a branch

[Stefan Sperling]

[ Taking this discussion back from dev@ to users@ ]

On Fri, May 07, 2010 at 05:15:25PM +1000, Daniel Becroft wrote:
> it sounds
> as though creating branches from mixed-revision working copies will
> cause problems with merging.

The implications of mixed-revision working copies on tree conflicts
have been discussed on the users@ list a lot.
See for instance http://svn.haxx.se/users/archive-2009-08/0748.shtml

To avoid problems resulting from mixed-revision copies,
URL->URL copies should always be used to create branches.
Use working copy -> URL copies only if you really need to create
copies of things which differ from anything else in the repository,
and know how to deal with consequences.

For instance, the Subversion project itself creates its release
tags from working copies, after adjusting version numbers from
e.g. 1.6.x to something fixed like 1.6.12. This avoids version-numbering
churn on the release branch itself.


Stefan

Re: Cannot reintegrate feature branch

[Stefan Sperling]

On Fri, May 07, 2010 at 02:16:20PM +0200, Stefan Sperling wrote:
> On Fri, May 07, 2010 at 11:35:16AM +0800, Jean Seurin wrote:
> > Hi Stefan,
> > 
> > unfortunately even with a fresh branch check out, it would not pick
> > up the missing changes, that is the problem.
> 
> Can you try to find out why it would merge the remaining changes?

s/would/would not/

Sorry,
Stefan

RE: Trouble with authorization

[K F]

> > From: K F [mailto:cmkfo...@yahoo.com]
 
> > Sent: 05 May 2010 20:43
> > 
> > The 
repo in on a Unix box located at svnrepo/sandbox 
> > accessing
 via tortoise on a windows machine with the latest 
> > 
releases. When I try to do a commit as user dev1, psswd dev1, 
> 
> I get the following error:
> >  
> > Command: 
Commit 
> > Error: Commit failed (details follow):  
> 
> Error: Authorization failed  
> > Finished!:   
> 
>  
> > I am not sure what is wrong. I did some searching on
 the web 
> > and can't find anything wrong with what I am 
doing. Here is 
> > what I have in the pertinent files.
>
 >  
> > passwd file:
> > dev1 = dev1
> > 
dev2 = dev2
> > dev3 = dev3
> >  
> > authz 
file:
> > [aliases]
> >  
> > [groups]
>
 > deva = dev1, dev2
> > devb = dev3
> >  
> 
> [svnrepo/sandbox:/]
> > deva = rw
> > devb = r
>
 
> Personally I had some issues with using [groups] that I 
>
 unfotunately did
> not have time to resolve.  I suggest that you 
start by using the
> usernames (dev1 etc) directly in the authz 
file to test:
> 
> Also, I think that [svnrepo/sandbox:/] is
 wrong.  I would only ever
> expect to see one name before the 
slash (a specific repo in a 
> parentpath
> setup) then the 
path within the repo comes after the ":/".  
> 
> 
[sandbox:/]
> dev1 = rw
> dev2 = rw
> dev3 = r
>
 
> If you only have one repo / are not using parentpath then you 
can just
> set the default global access level:
> 
> 
[/]
> dev1 = rw
> dev2 = rw
> dev3 = r
> 
>
 Are you using parentpath in your setup?  Unless your client 
> is
 1.6.11+,
> you need to grant read access to the root (you do seem
 to be 
> doing that,
> just thought it worth mentioning).
>
 
> Finally, a link to path-based authorization in the nightly red
 book:
>
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.h 
tml 
>
 
> 
> ~ mark c
> 
> > svnserve.conf file:
>
 > [general]
> > anon-access=none
> > 
auth-access=write
> >  
> > password-db=passwd
>
 >  
> > authz-db=authz
> > 

> From: K F 
[mailto:cmkfo...@yahoo.com]
 
> Sent: 06 May 2010 13:36
> 
> Mark,
> 
>
 I looked at the link you offered for Path-Based Authorization 
> 
and really didn't see anything that I haven't tried. Based on 
> 
your suggestions, to get it to work I am not using groups and 
> 
am simply using the usernames. 
> 
> [/]
> dev1 = rw
>
 dev2 = rw
> dev3 = r
> 
> As you can see I am also 
using the global level access. This 
> all seems to work. I would 
still like to try and get the 
> groups to work if anyone has any 
other ideas.
> 
> Thanks,
> Rich
>
Dang!  I 
missed the obvious problem which is that according to the Red
Book 
link you need to prefix group names with '@' which gives:-

> 
authz file:
> [aliases]
>  
> [groups]
> deva = 
dev1, dev2
> devb = dev3
>  
> [svnrepo/sandbox:/]
>
 @deva = rw
> @devb = r

...let me know if it works!

(and
 for completeness: Aliases need to be prefixed by '&' which does
work
 for me)  Hmm, perhaps my problem with groups was trying to create
groups
 just of aliases e.g.

[aliases]
user1=joe90
user2=adameve
user3=spod

[groups]
devs=&user1,
 &user2
test=&user2, &user3

[/]
@devs = rw
@test
 = r

Can anyone else confirm if this should /does (not) work?

~
 mark c


Mark,

I had seen that in the book also and tried it with no luck. My latest try was:

[aliases]
dev10 = dev1
dev20 = dev2
dev30 = dev3

[groups]
deva = &dev10, &dev20
devb = &dev30

[/]
&deva = rw
&devb = r

This returns an error on commit of:
Error: Commit failed (details follow):  
Error: An authz rule refers to alias '&deva', which is undefined  

Still looking at it to see if it something I am just missing sometjhing or 
doing something wrong.

Rich





  

How do I use "^" in command-line paths?

[tstone-barcard]

The SVN Book uses a path syntax throughout the narrative that prefixes
a "^". I'm continually baffled by the use of "^" in the svn-book
(http://svnbook.red-bean.com) because I cannot get it to work.

What is this shortcut? When does it work? Does it need to be set?

I've tried using it, but it never works (v1.6.3).

I've used other "path shortcuts" like environment variables, but would
love to understand just what the authors are trying to demonstrate in
the book.

Thanks,
Tim

Re: How do I use "^" in command-line paths?

[Stefan Sperling]

On Fri, May 07, 2010 at 07:07:41AM -0700, tstone-barcard wrote:
> The SVN Book uses a path syntax throughout the narrative that prefixes
> a "^". I'm continually baffled by the use of "^" in the svn-book
> (http://svnbook.red-bean.com) because I cannot get it to work.
> 
> What is this shortcut? When does it work? Does it need to be set?

"^/" expands to the value of the repository root.
svn info prints the repository root as well -- that URL is
what will be used:

$ svn info | grep Root
Repository Root: file:///tmp/svn-sandbox/repos
$ svn ls file:///tmp/svn-sandbox/repos
branch/
trunk/
$ svn ls ^/
branch/
trunk/

> I've tried using it, but it never works (v1.6.3).

It should just work on Linux/Mac.

On windows, ^ is a special character for the cmd shell,
so you must escape it: use ^^/ instead of ^/

Stefan

Re: How do I use "^" in command-line paths?

[Stanimir Stamenkov]

Fri, 7 May 2010 07:07:41 -0700 (PDT), /tstone-barcard/:

The SVN Book uses a path syntax throughout the narrative that prefixes 
a "^". I'm continually baffled by the use of "^" in the svn-book 
(http://svnbook.red-bean.com) because I cannot get it to work.


What is this shortcut? When does it work? Does it need to be set?

I've tried using it, but it never works (v1.6.3).

I've used other "path shortcuts" like environment variables, but would 
love to understand just what the authors are trying to demonstrate in 
the book.


The caret (^) notation works only inside a working copy 
:


In Subversion 1.6, a new caret (^) notation was introduced as a 
shorthand for “the URL of the repository's root directory”. For example:


$ svn list ^/tags/bigsandwich/

In this example, we're specifying a URL for the /tags/bigsandwich 
directory in the root of the repository. Note that this URL syntax 
only works when your current working directory is a working copy—the 
commandline client knows the repository's root URL by looking at the 
working copy's metadata.


You didn't state what OS you're on but on Windows you have to use ^^ as 
^ is a special command-line character - it is the escape character, e.g. 
you would need to use:


D:\...>svn merge ^^/branches/foo

On Windows you could also use double quotes around:

D:\...>svn merge "^/branches/foo"

--
Stanimir

Svndumpfilter option

[Giulio Troccoli]

I am a bit confused by the use --drop-empty-revs and --renumber-revs. In my 
view, --renumber-revs is useless.

Let's suppose that I have 3 directories in my repository: A committed in 
revision 1, B in revision 2 and C in revision 3

If I run

svndumpfilter exclude B < dumpfile

I expect revision 2 to be empty, but still there.

If I run

svndumpfilter exclude B --drop-empty-revs < dumpfile

I expect revision 2 to not be there at all, and therefore revision 3 becomes 
revision 2. I don't see the use of --renumber-revs.

Am I missing something?

G




Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447

Re: Unable to commit files : Server sent unexpected return value (400 Bad Request) in response

[robert mena]

Well,

After digging a while I found that the problem was due to a transparent
proxy between my machine and the server.

On Thu, May 6, 2010 at 11:29 AM, robert mena  wrote:

> Hi,
>
> I have a CentOS 5.4 with standard subversion + webdav access.  I am facing
> a problem.  I can access the repository e checkout the files but when I try
> to commit I get errors such as the example below
>
> Some of selected resources were not committed.
> RA layer request failed
> svn: Commit failed (details follow):
> svn: Server sent unexpected return value (400 Bad Request) in response to
> MKACTIVITY request for
> '/svn/repos/!svn/act/b7856539-4f3e-bc49-973e-2a56292a7f5d'
>
> The client is Eclipse galileo sr2 with the subversion plugin.
>
>
>

Active-Active Clustering with Subversion

[BD]

Hi All,

I'm starting a new project to consolidate all svn repos across our company
into a single instance. Originally we looked at doing a active-passive
cluster, but after looking at the loads on the current individual svn repos,
we are thinking that an active-active cluster would be preferable.

My question is, is it possible/safe to have two apache/svn nodes accessing
the same repo on the same storage system, shared out via nfs v3? Of course
the repo DB will formated with type FSFS, but we are concerned about data
corruption with multiple nodes doing commits to the same repo. Does anyone
have any experience using svn in this or a similar configuration?

Thanks
B

RE: Trouble with authorization

[K F]

> > From: K F [mailto:cmkfo...@yahoo.com]
 
> > Sent: 05 May 2010 20:43
> > 
> > The 
repo in on a Unix box located at svnrepo/sandbox 
> > accessing
 via tortoise on a windows machine with the latest 
> > 
releases. When I try to do a commit as user dev1, psswd dev1, 
> 
> I get the following error:
> >  
> > Command: 
Commit 
> > Error: Commit failed (details follow):  
> 
> Error: Authorization failed  
>
 > Finished!:   
> 
>  
> > I am not sure what is wrong. I did some searching on
 the web 
> > and can't find anything wrong with what I am 
doing. Here is 
> > what I have in the pertinent files.
>
 >  
> > passwd file:
> > dev1 = dev1
> > 
dev2 = dev2
> > dev3 = dev3
> >  
> > authz 
file:
> > [aliases]
> >  
> > [groups]
>

 > deva = dev1, dev2
> > devb = dev3
> >  
> 
> [svnrepo/sandbox:/]
> > deva = rw
> > devb = r
>

 
> Personally I had some issues with using [groups] that I 
>

 unfotunately did
> not have time to resolve.  I suggest that you 
start by using the
> usernames (dev1 etc) directly in the authz 
file to test:
> 
> Also, I think that [svnrepo/sandbox:/] is
 wrong.  I would only ever
> expect to see one name before the 
slash (a specific repo in a 
> parentpath
> setup) then the 
path within the repo comes after the ":/".  
> 
> 
[sandbox:/]
> dev1 = rw
> dev2 = rw
> dev3 = r
>
 
> If you only have one repo / are not using parentpath then you 
can just
> set the default global access level:
> 
> 
[/]
> dev1 = rw
> dev2 = rw
> dev3 = r
> 
>

 Are you using parentpath in your setup?  Unless your client 
> is
 1.6.11+,
> you need to grant read access to the root (you do seem
 to be 
> doing that,
> just thought it worth mentioning).
>

 
> Finally, a link to path-based authorization in the nightly red
 book:
>
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.h  
tml 
>
 
> 
> ~ mark c
> 
> > svnserve.conf file:
>

 > [general]
> > anon-access=none
> > 
auth-access=write
> >  
> > password-db=passwd
>
 >  
> > authz-db=authz
> > 

> From: K F 
[mailto:cmkfo...@yahoo.com]
 
> Sent: 06 May 2010 13:36
> 
> Mark,
> 
>

 I looked at the link you offered for Path-Based Authorization 
> 
and really didn't see anything that I haven't tried. Based on 
> 
your suggestions, to get it to work I am not using groups and 
> 
am simply using the usernames. 
> 
> [/]
> dev1 = rw
>

 dev2 = rw
> dev3 = r
> 
> As you can see I am also 
using the global level access. This 
> all seems to work. I would 
still like to try and get the 
> groups to work if anyone has any 
other ideas.
> 
> Thanks,
> Rich
>
Dang!  I 
missed the obvious problem which is that according to the Red
Book 
link you need to prefix group names with '@' which gives:-

> 
authz file:
> [aliases]
>  
> [groups]
> deva = 
dev1, dev2
> devb = dev3
>  
> [svnrepo/sandbox:/]
>

 @deva = rw
> @devb = r

...let me know if it works!

(and

 for completeness: Aliases need to be prefixed by '&' which does
work

 for me)  Hmm, perhaps my problem with groups was trying to create
groups

 just of aliases e.g.

[aliases]
user1=joe90
user2=adameve
user3=spod

[groups]
devs=&user1,

 &user2
test=&user2, &user3

[/]
@devs = rw
@test

 = r

Can anyone else confirm if this should /does (not) work?

~
 mark c


Mark,

I had seen that in the book also and 
tried it with no luck. My latest try was:

[aliases]
dev10 = 
dev1
dev20 = dev2
dev30 = dev3

[groups]
deva = 
&dev10, &dev20
devb = &dev30

[/]
&deva = rw
&devb
 = r

This returns an error on commit of:
Error: Commit failed 
(details follow):  
Error: An authz rule refers to alias '&deva',
 which is undefined  

Still looking at it to see if it something I
 am just missing sometjhing or doing something wrong.

Rich

===

So I inserted an & instead of a @ at the bottom and that fixed things.

@deva = rw
@devb = r

Just to clarify, in order to use authz you need to set up aliases? Unless I set 
aliases up it doesn't appear to work. Looking at the book, I do not see why 
aliases are required. If anyone can explain the reasoning or explain why I am 
wrong I would appreciate it.

Thanks,
Rich



  

Re: Active-Active Clustering with Subversion

[Ryan Schmidt]

On May 7, 2010, at 10:26, BD wrote:

> I'm starting a new project to consolidate all svn repos across our company 
> into a single instance. Originally we looked at doing a active-passive 
> cluster, but after looking at the loads on the current individual svn repos, 
> we are thinking that an active-active cluster would be preferable.
> 
> My question is, is it possible/safe to have two apache/svn nodes accessing 
> the same repo on the same storage system, shared out via nfs v3? Of course 
> the repo DB will formated with type FSFS, but we are concerned about data 
> corruption with multiple nodes doing commits to the same repo. Does anyone 
> have any experience using svn in this or a similar configuration? 

Hosting a repo on NFS can work, but so many people write here for help after 
trying to do so and finding it doesn't work for them. It depends on whether 
your NFS implementation supports proper locking.

I've been told before that to do active-active clustering, you would want to 
have the repository data located on a cluster filesystem (e.g. Apple Xsan) 
accessed by both servers. Otherwise data corruption would indeed be a concern.

But, these days, you could have a simpler setup with two (or more) standalone 
servers which mirror each other's contents using svnsync. Write requests would 
have to happen on a single master server only, but the mirrors could be 
configured with a writethrough proxy to make this transparent. You should be 
able to find documentation on setting these up.

RE: Trouble with authorization

[K F]

> > From: K F [mailto:cmkfo...@yahoo.com]
 
> > Sent: 05 May 2010 20:43
> > 
> > The 
repo in on a Unix box located at svnrepo/sandbox 
> > accessing
 via tortoise on a windows machine with the latest 
> > 
releases. When I try to do a commit as user dev1, psswd dev1, 
> 
> I get the following error:
> >  
> > Command: 
Commit 
> > Error: Commit failed (details follow):  
> 
> Error: Authorization failed  
>
 > Finished!:   
> 
>  
> > I am not sure what is wrong. I did some searching on
 the web 
> > and can't find anything wrong with what I am 
doing. Here is 
> > what I have in the pertinent files.
>
 >  
> > passwd file:
> > dev1 = dev1
> > 
dev2 = dev2
> > dev3 = dev3
> >  
> > authz 
file:
> > [aliases]
> >  
> > [groups]
>


 > deva = dev1, dev2
> > devb = dev3
> >  
> 
> [svnrepo/sandbox:/]
> > deva = rw
> > devb = r
>


 
> Personally I had some issues with using [groups] that I 
>


 unfotunately did
> not have time to resolve.  I suggest that you 
start by using the
> usernames (dev1 etc) directly in the authz 
file to test:
> 
> Also, I think that [svnrepo/sandbox:/] is
 wrong.  I would only ever
> expect to see one name before the 
slash (a specific repo in a 
> parentpath
> setup) then the 
path within the repo comes after the ":/".  
> 
> 
[sandbox:/]
> dev1 = rw
> dev2 = rw
> dev3 = r
>
 
> If you only have one repo / are not using parentpath then you 
can just
> set the default global access level:
> 
> 
[/]
> dev1 = rw
> dev2 = rw
> dev3 = r
> 
>


 Are you using parentpath in your setup?  Unless your client 
> is
 1.6.11+,
> you need to grant read access to the root (you do seem
 to be 
> doing that,
> just thought it worth mentioning).
>


 
> Finally, a link to path-based authorization in the nightly red
 book:
>
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.h   
tml
 
>
 
> 
> ~ mark c
> 
> > svnserve.conf file:
>


 > [general]
> > anon-access=none
> > 
auth-access=write
> >  
> > password-db=passwd
>
 >  
> > authz-db=authz
> > 

> From: K F 
[mailto:cmkfo...@yahoo.com]
 
> Sent: 06 May 2010 13:36
> 
> Mark,
> 
>


 I looked at the link you offered for Path-Based Authorization 
> 
and really didn't see anything that I haven't tried. Based on 
> 
your suggestions, to get it to work I am not using groups and 
> 
am simply using the usernames. 
> 
> [/]
> dev1 = rw
>


 dev2 = rw
> dev3 = r
> 
> As you can see I am also 
using the global level access. This 
> all seems to work. I would 
still like to try and get the 
> groups to work if anyone has any 
other ideas.
> 
> Thanks,
> Rich
>
Dang!  I 
missed the obvious problem which is that according to the Red
Book 
link you need to prefix group names with '@' which gives:-

> 
authz file:
> [aliases]
>  
> [groups]
> deva = 
dev1, dev2
> devb = dev3
>  
> [svnrepo/sandbox:/]
>


 @deva = rw
> @devb = r

...let me know if it works!

(and


 for completeness: Aliases need to be prefixed by '&' which does
work


 for me)  Hmm, perhaps my problem with groups was trying to create
groups


 just of aliases e.g.

[aliases]
user1=joe90
user2=adameve
user3=spod

[groups]
devs=&user1,


 &user2
test=&user2, &user3

[/]
@devs = rw
@test


 = r

Can anyone else confirm if this should /does (not) work?

~
 mark c


Mark,

I had seen that in the book also and 
tried it with no luck. My latest try was:

[aliases]
dev10 = 
dev1
dev20 = dev2
dev30 = dev3

[groups]
deva = 
&dev10, &dev20
devb = &dev30

[/]
&deva = rw
&devb

 = r

This returns an error on commit of:
Error: Commit failed 
(details follow):  
Error: An authz rule refers to alias '&deva',
 which is undefined  

Still looking at it to see if it something I
 am just missing sometjhing or doing something wrong.

Rich

===

So
 I inserted an & instead of a @ at the bottom and that fixed things.

@deva
 = rw
@devb = r

Just to clarify, in order to use authz you 
need to set up aliases? Unless I set aliases up it doesn't appear to 
work. Looking at the book, I do not see why aliases are required. If 
anyone can explain the reasoning or explain why I am wrong I would 
appreciate it.

Thanks,
Rich


===


More testing reveals that aliases are not needed. Here is what works:

With Groups

[aliases]
dev10 = dev1
dev20 = dev2
dev30 = dev3

[groups]
deva = &dev10, &dev20
devb = &dev30

[/]
@deva = rw
@devb = r

--

Without Groups



[aliases]



[groups]

deva = dev1, dev2

devb = dev3



[/]

@deva = rw

@devb = r

My problem was that I thought the ampersand was only necessary if you used 
aliases.

I hope this helps anyone else that may have had problems.

Rich




  

Reading an old SVN database

[Felix E. Klee]

>From a server that is not running anymore, I have a backup of the Subversion
database: /var/db/svn

Now I want to check out the latest version of every repository in that
database. What's the best way to proceed?

Re: Active-Active Clustering with Subversion

[BD]

Thanks for the reply Ryan,

I'll have to look further into how locking is setup on our NetApp FAS 3070.
We were also considering using GFS to handle the locking, have you heard
anything about users having multiple svn compute nodes connecting to a repo
on GFS and using distributed lock manager?

I saw that some people were using svnsync and writethrough proxying. I was
concerned about the read-only copies keeping up during nightly builds when
our developers will often go through thousands of commits. I'll have to look
into the documentation for svnsync a little closer.

B

On Fri, May 7, 2010 at 11:50 AM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:

>
> On May 7, 2010, at 10:26, BD wrote:
>
> > I'm starting a new project to consolidate all svn repos across our
> company into a single instance. Originally we looked at doing a
> active-passive cluster, but after looking at the loads on the current
> individual svn repos, we are thinking that an active-active cluster would be
> preferable.
> >
> > My question is, is it possible/safe to have two apache/svn nodes
> accessing the same repo on the same storage system, shared out via nfs v3?
> Of course the repo DB will formated with type FSFS, but we are concerned
> about data corruption with multiple nodes doing commits to the same repo.
> Does anyone have any experience using svn in this or a similar
> configuration?
>
> Hosting a repo on NFS can work, but so many people write here for help
> after trying to do so and finding it doesn't work for them. It depends on
> whether your NFS implementation supports proper locking.
>
> I've been told before that to do active-active clustering, you would want
> to have the repository data located on a cluster filesystem (e.g. Apple
> Xsan) accessed by both servers. Otherwise data corruption would indeed be a
> concern.
>
> But, these days, you could have a simpler setup with two (or more)
> standalone servers which mirror each other's contents using svnsync. Write
> requests would have to happen on a single master server only, but the
> mirrors could be configured with a writethrough proxy to make this
> transparent. You should be able to find documentation on setting these up.
>
>

Re: Reading an old SVN database

[Ryan Schmidt]

On May 7, 2010, at 10:09, Felix E. Klee wrote:

> From a server that is not running anymore, I have a backup of the Subversion 
> database: /var/db/svn

It would have been better to back up a dumpfile of the repository, since 
dumpfiles are portable.


> Now I want to check out the latest version of every repository in that 
> database. What's the best way to proceed?

Since you only have the old database, your best bet is to get a machine with 
the same processor architecture as the old server, and a version of Subversion 
at least as new, and access the repository. If the repository is using 
BerkeleyDB (BDB) you should also use the same version of BerkeleyDB that the 
old server was using, otherwise you may need to do some upgrades on the 
repository before you can read it.

RE: Reading an old SVN database

[Bob Archer]

> On May 7, 2010, at 10:09, Felix E. Klee wrote:
> 
> > From a server that is not running anymore, I have a backup of the
> Subversion database: /var/db/svn
> 
> It would have been better to back up a dumpfile of the repository, since
> dumpfiles are portable.
> 
> 
> > Now I want to check out the latest version of every repository in that
> database. What's the best way to proceed?
> 
> Since you only have the old database, your best bet is to get a machine
> with the same processor architecture as the old server, and a version of
> Subversion at least as new, and access the repository. If the repository
> is using BerkeleyDB (BDB) you should also use the same version of
> BerkeleyDB that the old server was using, otherwise you may need to do
> some upgrades on the repository before you can read it.

Might it just be easier using svn 1.6.11 to access each repository using the 
file:// protocol and do a check out?

BOb

Re: Active-Active Clustering with Subversion

[Les Mikesell]

On 5/7/2010 10:26 AM, BD wrote:

Hi All,

I'm starting a new project to consolidate all svn repos across our
company into a single instance. Originally we looked at doing a
active-passive cluster, but after looking at the loads on the current
individual svn repos, we are thinking that an active-active cluster
would be preferable.

My question is, is it possible/safe to have two apache/svn nodes
accessing the same repo on the same storage system, shared out via nfs
v3? Of course the repo DB will formated with type FSFS, but we are
concerned about data corruption with multiple nodes doing commits to the
same repo. Does anyone have any experience using svn in this or a
similar configuration?


The underlying disk system itself is probably the bottleneck so 
distributing access isn't likely to help performance that much anyway. 
I'd expect bigger gains from beefing up the storage unit (make the raid 
distribute over more drives, don't share those drives with other work, 
use a controller with battery-backed buffering, etc.).


--
  Les Mikesell
   lesmikes...@gmail.com

RE: Trouble with authorization

[Bob Archer]

> More testing reveals that aliases are not needed. Here is what works:
> 
> With Groups

I assume here you mean "with aliases"

> 
> [aliases]
> dev10 = dev1
> dev20 = dev2
> dev30 = dev3
> 
> [groups]
> deva = &dev10, &dev20
> devb = &dev30
> 
> [/]
> @deva = rw
> @devb = r
> 
> --
> 
> Without Groups

and here you mean "without aliases"

> 
> [aliases]
> 
> [groups]
> deva = dev1, dev2
> devb = dev3
> 
> [/]
> @deva = rw
> @devb = r
> 
> My problem was that I thought the ampersand was only necessary if you used
> aliases.
> 
> I hope this helps anyone else that may have had problems.
> 
> Rich

In both cases you are using groups.


BOb

Re: Reading an old SVN database

[Ryan Schmidt]

On May 7, 2010, at 12:03, Bob Archer wrote:

>> On May 7, 2010, at 10:09, Felix E. Klee wrote:
>> 
>>> From a server that is not running anymore, I have a backup of the
>> Subversion database: /var/db/svn
>> 
>> It would have been better to back up a dumpfile of the repository, since
>> dumpfiles are portable.
>> 
>> 
>>> Now I want to check out the latest version of every repository in that
>> database. What's the best way to proceed?
>> 
>> Since you only have the old database, your best bet is to get a machine
>> with the same processor architecture as the old server, and a version of
>> Subversion at least as new, and access the repository. If the repository
>> is using BerkeleyDB (BDB) you should also use the same version of
>> BerkeleyDB that the old server was using, otherwise you may need to do
>> some upgrades on the repository before you can read it.
> 
> Might it just be easier using svn 1.6.11 to access each repository using the 
> file:// protocol and do a check out?

Yes, but as I said, that svn 1.6.11 will have to be compiled against the same 
version of BDB as the old server's Subversion was (if the repository is using 
BDB), and will have to be running on a server of the same processor 
architecture (at least, that always used to be the advice with BDB; I don't 
know for a fact whether this still applies for FSFS).

RE: Trouble with authorization

[K F]

You are correct. With and with out aliases. Sometimes my fingers just don't 
listen to what my mind tells them to type.

--- On Fri, 5/7/10, Bob Archer  wrote:

From: Bob Archer 
Subject: RE: Trouble with authorization
To: "K F" , "MarkCooke" 
Cc: "Subversion Users" 
Date: Friday, May 7, 2010, 5:08 PM

> More testing reveals that aliases are not needed. Here is what works:
> 
> With Groups

I assume here you mean "with aliases"

> 
> [aliases]
> dev10 = dev1
> dev20 = dev2
> dev30 = dev3
> 
> [groups]
> deva = &dev10, &dev20
> devb = &dev30
> 
> [/]
> @deva = rw
> @devb = r
> 
> --
> 
> Without Groups

and here you mean "without aliases"

> 
> [aliases]
> 
> [groups]
> deva = dev1, dev2
> devb = dev3
> 
> [/]
> @deva = rw
> @devb = r
> 
> My problem was that I thought the ampersand was only necessary if you used
> aliases.
> 
> I hope this helps anyone else that may have had problems.
> 
> Rich

In both cases you are using groups.


BOb




  

Re: Active-Active Clustering with Subversion

[BD]

Thanks Les,

I know NFS itself can certainly be a bottleneck. However, we will be
devoting at least three shelves of disk on our NetApp 3070 which in our
standard RAID group size will make for about 38 data spindles and we will
have have 256 GB of read cache per head on a two head storage system.

Initially we dont expect compute capacity to be a problem with our SVN
setup, but we are a growing company and are planning this SVN cluster to be
scalable with the organization.

So the question remains, taking physical restraints out of the question, is
there anyone out there who knows about managing the risks assocciated with
having two or more apache/svn nodes accessing repos that are stored on a
shared NFS storage system, with the SVN DBs using FSFS.

B

On Fri, May 7, 2010 at 1:05 PM, Les Mikesell  wrote:

> On 5/7/2010 10:26 AM, BD wrote:
>
>> Hi All,
>>
>> I'm starting a new project to consolidate all svn repos across our
>> company into a single instance. Originally we looked at doing a
>> active-passive cluster, but after looking at the loads on the current
>> individual svn repos, we are thinking that an active-active cluster
>> would be preferable.
>>
>> My question is, is it possible/safe to have two apache/svn nodes
>> accessing the same repo on the same storage system, shared out via nfs
>> v3? Of course the repo DB will formated with type FSFS, but we are
>> concerned about data corruption with multiple nodes doing commits to the
>> same repo. Does anyone have any experience using svn in this or a
>> similar configuration?
>>
>
> The underlying disk system itself is probably the bottleneck so
> distributing access isn't likely to help performance that much anyway. I'd
> expect bigger gains from beefing up the storage unit (make the raid
> distribute over more drives, don't share those drives with other work, use a
> controller with battery-backed buffering, etc.).
>
> --
>  Les Mikesell
>   lesmikes...@gmail.com
>

Re: which is better?

[David Weintraub]

My understanding is that "worker" is faster because it uses threads,
but not all modules that work with Apache are thread safe. There's a
problem with PHP because some third party libraries that PHP might use
are not thread safe. Perl before 5.6 isn't thread safe, etc. Redhat,
by default, comes with prefork because of this.

However, I haven't found any document that states to avoid using
Subversion with "worker" due to threads. If all you're running is
Subversion, you can probably use "worker". But, if you use any other
Apache modules, you have to be careful. For example, if you use ViewVC
or software like this, it could be  not thread safe, so you need to
use prefork.

If speed is important, you might want to avoid HTTP altogether and use
svn or svn+ssh.

My experience shows that the server isn't usually the bottleneck with
Subversion. The issues tend to be with the network and client systems.

On Thu, May 6, 2010 at 11:49 PM, west alto  wrote:
> Hi,
>
> Just a question.
>
> I have a server with the following specs:
>
> ESXi guest server
> 2 cpu
> 4 gig memory
>
> Which is better option for running svn and apache, pre-fork or worker?
>
>
> Thanks,
>
>
> West
>



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

Is there any way of extending the set of keywords recognized/expanded by Subversion?

[Edward Knoll]

Our company is integrating Subversion into a larger process environment,
and there are now other kinds of artifacts identifiers associated with
our repository which are outside of Subversion.   It would be handy if
there were a way to extend the set of keywords recognized/expanded by
Subversion to include these external artifact identifiers.

RE: Is there any way of extending the set of keywords recognized/expanded by Subversion?

[Bob Archer]

> Our company is integrating Subversion into a larger process environment,
> and there are now other kinds of artifacts identifiers associated with our
> repository which are outside of Subversion.   It would be handy if there
> were a way to extend the set of keywords recognized/expanded by Subversion
> to include these external artifact identifiers.

Not that I am aware of. Here we use our build scripts to inject stuff like this 
into the projects and source. The values probably aren't specific to source 
control I assume?

BOb