subversion externals issue

2012-03-01 Thread Neson Maxmelbin (RBEI/EMT4) 
Hello ,

I have externals from other repo's configured in my master project under trunk.
When I tag the trunk and then checkout the tag, the externals are not checked 
out.
When I tag the entire repo and then checkout the tag, the externals are checked 
out. Is this the normal behavior? [I tried from Tortoise SVN]

Mit freundlichen Grüßen / Best regards

Maxmelbin Neson

SVN Sunc problem

2012-03-01 Thread suhas malusare 
Hello,

I have a SVN Master-Slave setup,
The slave repo gets updated through svnsync process,
but while observing the sync process I figured out that the Integration
branch is not getting the the updates from its Master branch.

please help me on this issue

Thanks,
Suhas Malusare

Re: SVN Sunc problem

2012-03-01 Thread Thorsten Schöning 
Guten Tag suhas malusare,
am Donnerstag, 1. März 2012 um 10:08 schrieben Sie:

> I have a SVN Master-Slave setup,
> The slave repo gets updated through svnsync process,
> but while observing the sync process I figured out that the Integration
> branch is not getting the the updates from its Master branch.

Which versions of svnsync are you running on the slave? I may be wrong
but I think I've read something about svnsync is able to sync just
specific paths of the source repository, but it is not mentioned in
the svnbook. You could test your setup by just committing into one of
the other branches and see if this commit gets synced. Regarding to
your screenshot it may just be that your sync process failes in
general after the last revision 4568.

http://svnbook.red-bean.com/en/1.7/svn.ref.svnsync.html

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: Subversion Exception in 1.7.1/2

2012-03-01 Thread coolie 
4073 says this is supposed to have been fixed. I'm now on 1.7.5 and still 
have the same issue.

I can't use a relative path cos that is not where the libray is. I need 
absolute because some apps (viz VS 2010) require absolute paths for library 
references.

I have to put the libraries on the C drive so that they can be accessed by 
any user without them having to change the VS settings.

Daft thing is, it does actually check out the external library - I just get 
a MS exception report. I then have to do a cleanup and on subsequent 
updates I don't get the exception.

If this is not fixed then every user has to edit user specific VS settings 
whenever my project is checked out by them. The settings are then wrong for 
everybody else when it gets checked back in!

On Monday, 12 December 2011 13:04:47 UTC, Philip Martin wrote:
>
> coolie writes:
>
> > I am checking out a svn folder to Windows desktop, but have set the
> > svn:externals property on this folder to check out a lib at C:/lib:
> >
> > svn:externals  C:/lib
>
> This is issue 4073:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4073
>
> use a relative path such as "lib" rather than "C:/lib".
>
> -- 
> Philip
>
>

ubdefined reference error with v1.7.3

2012-03-01 Thread Ravish Nayak S. R. 
Hi All,

I am trying to build/install subversion 1.7.3 on 
rhe4-x86_64 platform, I come across with below error and I could able to
 move further..

~/subv/subversion/libsvn_repos/.libs/libsvn_repos-1.so.0: undefined reference 
to `svn_txdelta_to_svndiff2'

~/subv/subversion/libsvn_ra/.libs/libsvn_ra-1.so: undefined reference to 
`svn_compat_wrap_file_rev_handler'

~/subv//subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.so.0: undefined reference 
to `svn_txdelta_stream_create'

In
 the same forum I saw that one of the user gave solution saying it is 
looking for old svn(1.6) libraries try to delete old.. But in my case 
there is no old subversion libraries..

Could you please help me to fix above error..

Thanks,
Ravish

Re: Subversion Exception in 1.7.1/2

2012-03-01 Thread Stefan Sperling 
On Thu, Mar 01, 2012 at 03:08:55AM -0800, coolie wrote:
> 4073 says this is supposed to have been fixed. I'm now on 1.7.5 and still 
> have the same issue.
> 
> I can't use a relative path cos that is not where the libray is. I need 
> absolute because some apps (viz VS 2010) require absolute paths for library 
> references.

It seems that this has been fixed in trunk but the fix hasn't
been backported to 1.7.x.

Re: Subversion Exception in 1.7.1/2

2012-03-01 Thread Philip Martin 
Stefan Sperling  writes:

> On Thu, Mar 01, 2012 at 03:08:55AM -0800, coolie wrote:
>> 4073 says this is supposed to have been fixed. I'm now on 1.7.5 and still 
>> have the same issue.
>> 
>> I can't use a relative path cos that is not where the libray is. I need 
>> absolute because some apps (viz VS 2010) require absolute paths for library 
>> references.
>
> It seems that this has been fixed in trunk but the fix hasn't
> been backported to 1.7.x.

The 4073 fix doesn't allow absolute paths with drive letters.  It merely
prevents the assertion by extending the checking so that paths with
drive letters are treated as absolute and skipped.

-- 
Philip

Re: Subversion Exception in 1.7.1/2

2012-03-01 Thread Stefan Sperling 
On Thu, Mar 01, 2012 at 01:04:04PM +0100, Stefan Sperling wrote:
> On Thu, Mar 01, 2012 at 03:08:55AM -0800, coolie wrote:
> > 4073 says this is supposed to have been fixed. I'm now on 1.7.5 and still 
> > have the same issue.
> > 
> > I can't use a relative path cos that is not where the libray is. I need 
> > absolute because some apps (viz VS 2010) require absolute paths for library 
> > references.
> 
> It seems that this has been fixed in trunk but the fix hasn't
> been backported to 1.7.x.

Oh, and to be clear, these fixes replace the assertion with an
error message saying the externals definition is invalid because
it points to an absolute path.

Currently, externals definitions cannot point to absolute paths.
This might be fixed in the future, once multiple working copies
can share a single .svn directory.

For now, you'll have to run a separate checkout to C:\lib if you need
a subversion working copy there. If that doesn't help you, you'll
have to find some other way of working around this. It seems that
externals won't help you.

Re: Subversion Exception in 1.7.1/2

2012-03-01 Thread Stefan Sperling 
On Thu, Mar 01, 2012 at 01:01:23PM +, Philip Martin wrote:
> The 4073 fix doesn't allow absolute paths with drive letters.  It merely
> prevents the assertion by extending the checking so that paths with
> drive letters are treated as absolute and skipped.

Yes, I just realised that while reviewing the backport nomination :)

Re: Subversion Exception in 1.7.1/2

2012-03-01 Thread Philip Martin 
Stefan Sperling  writes:

> Currently, externals definitions cannot point to absolute paths.
> This might be fixed in the future, once multiple working copies
> can share a single .svn directory.

Perhaps, but perhaps not.  Allowing svn:externals to modify paths
outside a working copy has security implications.

-- 
Philip

Re: predecessor count for the root node-revision is wrong message

2012-03-01 Thread Justin Johnson 
On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson wrote:

> On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf  wrote:
>
>> Justin Johnson wrote on Wed, Feb 29, 2012 at 11:11:18 -0600:
>> > On Wed, Feb 29, 2012 at 10:35 AM, Daniel Shahaf 
>> wrote:
>> >
>> > > Justin Johnson wrote on Wed, Feb 29, 2012 at 10:25:38 -0600:
>> > > > On Wed, Feb 29, 2012 at 10:15 AM, Daniel Shahaf 
>> > > wrote:
>> > > > > - Are the failing revisions always small (eg: just a URL-URL
>> copy),
>> > > > >  or always large (eg: results of a merge)?
>> > > > >
>> > > > >
>> > > > As mentioned before, so far it appears to be 1) create a tag by
>> copying
>> > > an
>> > > > entire working copy of a branch to a URL, and 2) commit merge
>> results for
>> > > > an entire branch.
>> > > >
>> > >
>> > > That's not clear enough.  Could you show 'log -qv' of those revisions?
>> > >
>> > > A wc-to-URL copy could touch just one or two files (compare
>> > > `svn log -qv --stop-on-copy
>> > > http://svn.apache.org/repos/asf/subversion/tags/1.7.3`
>> )
>> > > or a full tree (http://subversion.apache.org/faq.html#in-place-import
>> ).
>> > > Which is it?
>> > >
>> > >
>> > The commits fail, so there is no revision to run this against.  Other
>> tags
>> > that have succeeded seem to just have one added path that is a copy of
>> the
>> > branch at revision x.  Does that answer your question?
>> >
>>
>> Yes, thanks.
>>
>> >
>> > > >
>> > > > > - Could you try setting the maximum cache size to zero?
>>  (svnserve:
>> > > > >  --memory-cache-size=0; mod_dav_svn: SVNInMemoryCacheSize 0)
>> > > > >
>> > > > >
>> > > > Apache is our server, so this is not applicable.
>> > >
>> > > SVNInMemoryCacheSize is applicable.
>> > >
>> >
>> > Sorry, I missed that one.  We have not specified SVNInMemoryCacheSize,
>> so
>> > we're using the default.
>>
>> ... so please try SVNInMemoryCacheSize 0, and see if that makes the
>> issue less frequent.
>>
>
> I'm a dork.  I will do so once I take care of the appropriate change
> control I have to deal with.  Thanks.
>

We made the change and problem is still occurring.

Re: predecessor count for the root node-revision is wrong message

2012-03-01 Thread Justin Johnson 
>
> > > > > - Are the failing revisions always small (eg: just a URL-URL copy),
>>> > > > >  or always large (eg: results of a merge)?
>>> > > > >
>>> > > > >
>>> > > > As mentioned before, so far it appears to be 1) create a tag by
>>> copying
>>> > > an
>>> > > > entire working copy of a branch to a URL, and 2) commit merge
>>> results for
>>> > > > an entire branch.
>>> > > >
>>> > >
>>> > > That's not clear enough.  Could you show 'log -qv' of those
>>> revisions?
>>> > >
>>> > > A wc-to-URL copy could touch just one or two files (compare
>>> > > `svn log -qv --stop-on-copy
>>> > > http://svn.apache.org/repos/asf/subversion/tags/1.7.3`
>>> )
>>> > > or a full tree (
>>> http://subversion.apache.org/faq.html#in-place-import).
>>> > > Which is it?
>>> > >
>>> > >
>>> > The commits fail, so there is no revision to run this against.  Other
>>> tags
>>> > that have succeeded seem to just have one added path that is a copy of
>>> the
>>> > branch at revision x.  Does that answer your question?
>>> >
>>>
>>> Yes, thanks.
>>>
>>> >
>>> > > >
>>> > > > > - Could you try setting the maximum cache size to zero?
>>>  (svnserve:
>>> > > > >  --memory-cache-size=0; mod_dav_svn: SVNInMemoryCacheSize 0)
>>> > > > >
>>> > > > >
>>> > > > Apache is our server, so this is not applicable.
>>> > >
>>> > > SVNInMemoryCacheSize is applicable.
>>> > >
>>> >
>>> > Sorry, I missed that one.  We have not specified SVNInMemoryCacheSize,
>>> so
>>> > we're using the default.
>>>
>>> ... so please try SVNInMemoryCacheSize 0, and see if that makes the
>>> issue less frequent.
>>>
>>
>> I'm a dork.  I will do so once I take care of the appropriate change
>> control I have to deal with.  Thanks.
>>
>
> We made the change and problem is still occurring.
>

The error occurs when a tag is created by copying from a URL to a URL as
well.  Note that the clients are all 1.6 at this time.  If it is helpful I
can try to setup some tests with a 1.7 client.

To make sure I understand the issue, should I be concerned about the
repositories and our ability to reproduce the history or recover from any
corruption that this bug may have caused?

Let me know if I can help in any other way.

Thanks.
Justin

Re: predecessor count for the root node-revision is wrong message

2012-03-01 Thread Daniel Shahaf 
Justin Johnson wrote on Thu, Mar 01, 2012 at 08:28:20 -0600:
> To make sure I understand the issue, should I be concerned about the
> repositories and our ability to reproduce the history or recover from any
> corruption that this bug may have caused?

The only known (and predicted) effect of the error is that some
revisions are wrongly skipped during a backward history walk --- such as
'log -r HEAD:0' does.

Creating an svnsync mirror is enough to fix the issue.  (There is no
need to check the mirror, even: if the mirror is written to by a 1.7
server (or a 1.7 svnsync over file://), the normal validation that
Jason's error logs show will be done automatically.)

Re: subversion externals issue

2012-03-01 Thread Ryan Schmidt 

On Mar 1, 2012, at 02:59, Neson Maxmelbin (RBEI/EMT4) wrote:

> I have externals from other repo's configured in my master project under 
> trunk.
> When I tag the trunk and then checkout the tag, the externals are not checked 
> out.
> When I tag the entire repo and then checkout the tag, the externals are 
> checked out. Is this the normal behavior? [I tried from Tortoise SVN]

That does not sound normal to me, and I have not heard of that happening before.

How is the tag created -- via "svn cp" from the trunk URL, or from a trunk 
working copy? If from a working copy, is it possible you had not run "svn up" 
on the working copy since before you added the externals definition?

If you check out the tag of trunk, does "svn propget svn:externals" show the 
externals definition or not?

I don't understand how you would "tag the entire repo" since the tags directory 
is inside the repo and you cannot copy something into itself.

You should show us a transcript demonstrating the problem, starting from the 
creation of an empty repository.

You should also indicate Subversion and OS versions, and the method used to 
serve the repository (svnserve, httpd, ...).

Feature request: allow for relative working copy paths in svn:externals definition

2012-03-01 Thread Humm, Markus 
Hello,

I'm currently learning SVN as we're planning to use it here in the near future.
Some of our projects are structured like this (MS Windows):

D:\Source\Project1
D:\Source\Project2
D:\Source\CommomLibraries

Where Project1 and Project2 are individual projects but both rely on files
which reside in D:\Source\CommomLibraries and should reside there.

One could try to use svn:externals not to set this up properly so that a 
Checkout of Project1 also checks out CommonLibraries and a update on Project1
also takes into account the changes you've made to CommonLibraries.

For me it seems that SVN 1.7.x currently cannot do this. What it could do is to 
place the structure described above on the repository in the same way, but in
the working copy the COmmonLibraries folder would have to reside below each 
Project folder:

D:\Source\Project1\CommonLibraries
D:\Source\Project2\CommonLibraries

But that is not what I want. What's even more:

I'm using Tortoise SVN 1.7.5 and this one managed to allow me to set up 
svn:externals like I assumed would work. It even commited the structure 
properly to the repository. But when I tried to checkout this project on 
another computer I get a assertion from svn itsself.

In File
 
»D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subversion\libsvn_wc\wc_db.c«,
 Zeile 2890: Assert-Anweisung schlug fehl
 (svn_dirent_is_ancestor(wcroot->abspath, local_abspath))

The local path of my svn:externals was this: 
D:/u/svnexternaltest2/gemeinsamme_bibliotheken

If I tried to use ../svnexternaltest2/gemeinsamme_bibliotheken instead Tortoise 
would detect that it contains a .. Or is a absolute path. Obviously either 
Tortoises or SVN's absolute path detection loginc is not 100% fool proof as 
well.

Back to my original issue: is there a way to get the structure I want via 
svn:externals,
Or would such a feature be a candidate for a feature request so we can get this 
in the future? If it get's a feature request, what actions can I do to speed up 
ist implementation? (programming it/submitting patches is unfortunatelly out of 
the question)

I really would not need absolute paths, relative paths would be sufficient, 
even if these
only supported a single level (../ is sufficient for me).

Best regards

Markus Humm

EB-EV
Entwicklung Elektronik

ebm-papst Mulfingen GmbH & Co. KG
Bachmühle 2
74673 Mulfingen

Phone.: +49 (7938) 81 531
Fax: +49 (7938) 81 9531
mailto: markus.h...@de.ebmpapst.com
http://www.ebmpapst.com

GreenTech - Ein Zeichen, mit dem wir Zeichen setzen. A symbol that defines 
standards.


ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart 
HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter 
Fuchs, Dr. Bruno Lindl, Thomas Wagner

Re: Feature request: allow for relative working copy paths in svn:externals definition

2012-03-01 Thread Stefan Sperling 
On Thu, Mar 01, 2012 at 04:35:32PM +0100, Humm, Markus wrote:
> Hello,
> 
> I'm currently learning SVN as we're planning to use it here in the near 
> future.
> Some of our projects are structured like this (MS Windows):
> 
> D:\Source\Project1
> D:\Source\Project2
> D:\Source\CommomLibraries
> 
> Where Project1 and Project2 are individual projects but both rely on files
> which reside in D:\Source\CommomLibraries and should reside there.
> 
> One could try to use svn:externals not to set this up properly so that a 
> Checkout of Project1 also checks out CommonLibraries and a update on Project1
> also takes into account the changes you've made to CommonLibraries.

You could use this kind of structure if you make "Source" a working copy
of a folder that has 2 or 3 externals defined that pull in the desired
subfolders.

And there is an alternative to using externals. You can use the
shallow working copy depth feature instead.
Put the folders side-by-side into the repository:

 /trunk/Project1
 /trunk/Project2
 /trunk/CommomLibraries

Then, either check out everything from /trunk, or check out sparse
working copies as follows:

 svn co --depth empty URL/trunk Source
 cd Source
 svn update --set-depth infinity CommomLibraries

 svn update --set-depth infinity Project1

 or:
 svn update --set-depth infinity Project2

This gives you the following working copy layout, with Project1
and Project2 being optionally excluded via depth:

 D:\Source\Project1
 D:\Source\Project2
 D:\Source\CommomLibraries

If you'd like to automate depth configuration during checkout there
is a helper script available at
https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py

It would be nice to have this kinf of "view" feature in Subversion's
core so that this would work without an external script.

> I'm using Tortoise SVN 1.7.5 and this one managed to allow me to set up 
> svn:externals like I assumed would work. It even commited the structure 
> properly to the repository. But when I tried to checkout this project on 
> another computer I get a assertion from svn itsself.
> 
> In File
>  
> »D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subversion\libsvn_wc\wc_db.c«,
>  Zeile 2890: Assert-Anweisung schlug fehl
>  (svn_dirent_is_ancestor(wcroot->abspath, local_abspath))
> 
> The local path of my svn:externals was this: 
> D:/u/svnexternaltest2/gemeinsamme_bibliotheken
>
> If I tried to use ../svnexternaltest2/gemeinsamme_bibliotheken instead 
> Tortoise would detect that it contains a .. Or is a absolute path. Obviously 
> either Tortoises or SVN's absolute path detection loginc is not 100% fool 
> proof as well.

Yes, this is a bug. Coincidentally this problem was discussed just today.
See http://svn.haxx.se/users/archive-2012-03/0012.shtml

Subversion Repository: naturally a single- or multi-Project versioning storage?

2012-03-01 Thread Pietro Moras 





Hi,
  Having
to develop two distinct, un-related Projects, I wonder whether it is
sensible to store them both into a unique Subversion Repository, or it is
natural to create two distinct Repositories, each one dedicated to a
unique Project.


In
other words, a Subversion Repository is naturally meant for more than
one, unrelated, independently versioned project, or not?
Thanks.
Yours,
 -
P.M.

RE: Subversion Repository: naturally a single- or multi-Project versioning storage?

2012-03-01 Thread Cooke, Mark 
> -Original Message-
> From: Pietro Moras [mailto:studio...@hotmail.com] 
> Sent: 01 March 2012 16:47
> Subject: Subversion Repository: naturally a single- or 
> multi-Project versioning storage?
> 
> Hi,
> 
> Having to develop two distinct, un-related Projects, I 
> wonder whether it is sensible to store them both into a 
> unique Subversion Repository, or it is natural to create two 
> distinct Repositories, each one dedicated to a unique Project.
> 
> 
> In other words, a Subversion Repository is naturally meant 
> for more than one, unrelated, independently versioned project, or not?
> 
> Thanks. Yours,
>  - P.M.
> 
I think this is subject to personal preferences.  So here is mine: separate 
repos for unrelated stuff.  It may well help in the future if you want to 
retire some old stuff and keep the rest for example...

Having said that you can work it both ways and having only one repo can (in the 
early days) simplify regular maintenance.

~ mark c

Re: Subversion Repository: naturally a single- or multi-Project versioning storage?

2012-03-01 Thread Les Mikesell 
On Thu, Mar 1, 2012 at 10:47 AM, Pietro Moras  wrote:
> Hi,
>
>     Having to develop two distinct, un-related Projects, I wonder whether it
> is sensible to store them both into a unique Subversion Repository, or it is
> natural to create two distinct Repositories, each one dedicated to a unique
> Project.
>
>
> In other words, a Subversion Repository is naturally meant for more than
> one, unrelated, independently versioned project, or not?

It works fine either way and for small projects won't make any
difference.  The trade-offs are that it may be harder to manage
equivalent user permissions across a set of separate repositories and
it will be more cumbersome to svnadmin dump/filter/load a large single
repository when it reaches a point where you need to do maintenance.

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

Re: Subversion Repository: naturally a single- or multi-Project versioning storage?

2012-03-01 Thread Ryan Schmidt 

On Mar 1, 2012, at 10:47, Pietro Moras wrote:

> Having to develop two distinct, un-related Projects, I wonder whether it 
> is sensible to store them both into a unique Subversion Repository, or it is 
> natural to create two distinct Repositories, each one dedicated to a unique 
> Project.
> 
> In other words, a Subversion Repository is naturally meant for more than one, 
> unrelated, independently versioned project, or not?

You can do it either way. And whether you choose a single repository or 
multiple repositories today, you can change your mind later: with some effort, 
a repository can be split, or multiple repositories can be combined.

I myself started with a single repository for all of my programming projects, 
but in recent years have switched to making a new repository for each project. 
I find this to be more flexible. For example years ago I wanted to open-source 
one of my private projects and put it on Google Code; before I could do so, I 
had to disentangle it from all the other projects in my monolithic repository, 
using svnadmin dump and svndumpfilter. It would have been easier if it had been 
in its own repository already. And if a project becomes obsolete, you can move 
its repository to archive media without impacting your other projects. You'll 
note this is also how various hosting companies do it: if you make a project on 
SourceForge or Google Code, you get a new repository just for that project; you 
don't share a repository containing other people's code.

However, the Apache Foundation, which hosts Subversion's repository, uses a 
single repository for all projects, and that works too. So it's up to you.

Re: predecessor count for the root node-revision is wrong message

2012-03-01 Thread Jason Wong 
On Tue, Feb 28, 2012 at 1:07 AM, Daniel Shahaf  wrote:
> Jason Wong wrote on Mon, Feb 27, 2012 at 07:36:39 -0800:
>> On Thu, Feb 16, 2012 at 12:14 PM, Daniel Shahaf  wrote:
>>
>> >
>> > The output from these two tells me two things:
>> >
>> > 1. The minfo-cnt value is reasonable (within a typical ballpark).
>> > That's relevant since minfo-cnt abnormalities were seen in another
>> > instance of the bug.
>> >
>> > 2. Everything else looks correct: the 'id:'/'pred:' headers are accurate,
>> > and the 'count:' header was incremented correctly.  The 'count:' header
>> > does, however, indicate that your repository has _in the past_ triggered
>> > an instance of the bug.
>>
>> This is true. We have seen the bug happen before. The first occurence
>> of this that we had seen was Dec. 7th, 2011, a few days after we went
>> from 1.6.16 to 1.7.1. That was the first time we had seen that happen.
>> At the time, we did not know about the cause and the developer who
>> had encountered the error didn't report it and was able to work
>
> Well, install fail2ban and have it mail you when that string appears
> in the logs?  I'll do so too...
>
>> around it. From the Apache logs we have:
>>
>>       [Wed Dec 07 15:16:36 2011] [error] [client 10.2.3.1] predecessor
>>               count for the root node-revision is wrong: found 59444,
>>               committing r59478  [409, #160004]
>>       [Wed Dec 07 15:33:47 2011] [error] [client 10.2.3.2] predecessor
>>               count for the root node-revision is wrong: found 59482,
>>               committing r59516  [409, #160004]
>>       [Wed Dec 07 15:35:19 2011] [error] [client 10.2.3.3] predecessor
>>               count for the root node-revision is wrong: found 59488,
>>               committing r59522  [409, #160004]
>
> As Stefan mentioned, these represent commit attempts that were rejected
> in order to prevent a new instance of the bug from entering the history.
>
>>       [Wed Dec 07 15:44:10 2011] [error] [client 10.2.3.4] predecessor
>>               count for the root node-revision is wrong: found 59505,
>>               committing r59539  [409, #160004]
>>
>> Of the ips above, the last line is from the build machine. The others
>> were from developer workstations. I mentioned the most recent two
>> times first as we were actually aware of the issue at that time and
>> it was recent so we knew to start looking into it. Between Dec. 7 and
>> Jan. 31, the bug has occurred 12 times, 3 of those times from the
>> build server. The rest are from workstations. This month, it has only
>> occurred once and it was from the build server.
>>
>
> What percentage of your commits are from the build server?
>
> Is there anything noteworthy about commits that were in progress around
> the time the bug occurred?  (their svn:date's would be near the time
> stamp in the httpd log)
>
>> Each of these times, the error has occurred in different parts of
>> the repository.
>>
>> Replies above. Sorry about the delay in replying. I have been really
>> busy of late. I will try and get the results this week, if not, it
>> will most likely be next week.
>>
>
> No problem.

Hi Daniel

Not sure if I should be replying to this post or the latest post, but
here is where we are at currently.

I have had a developer here create a build of the latest SVN code
with your changes you mentioned in r1294470 for the svnadmin verify
command. We have run 'svnadmin verify' against every revision of our
hotcopy of our repository taken when we first brought this issue to
the forums and are now tracking down each of the revisions to see
what actions were being done at those times.

>From the results, we see 25 error messages for predecessor count is
wrong and the first one appeared on January 26, 2011. Near that time
the following events occurred:
   Jan. 14, 2011 - svn upgraded from 1.6.6 to 1.6.15
   Jan. 14, 2011 - Apache HTTP server upgraded from 2.2.15 to 2.2.17
   Jan. 21, 2011 - repository was pruned to delete some binary files.

Between January and our upgrade in Dec. to 1.7.1, we have had about
14,000 revisions and seen only 25 instances of this node revision
issue. During the times we had these errors, we were using svn
versions 1.6.15 and 1.6.16.

Fail2ban from what I could find does not look like it has a Windows
port which I currently have my production environment hosted on.

Thanks.

Jason

Best approach to break up a repository

2012-03-01 Thread Mattius McLaughlin 

Hi,

  For some time now we've been lumping projects together in the same 
repository and serving them up using apache.  So our repository at 
/svn_data/data will look like this


 /
   /project_A
 /trunk
 /branches
 /tags
   /project_B
 /trunk
 /branches
 /tags
...

  And apache will serve that up with a directive like 'SVNPath 
/svn_data/repo/data'


  However, this is becoming a bit of a pain to work with for various 
reasons (e.g., replicating project_B, moving projects between sites) and 
I'd like to break each of those projects into separate repositories.  
Given the number of designers we have, it's a bit unreasonable to expect 
everyone to recreate every workspace so I'd like to keep all URLs the same.


  So I'd like to have repositories at /svn_data/repo/project_A, 
/svn_data/repo/project_B, /svn_data/repo/project_C, etc.  I've written 
something that can dump/load each one of the projects above and add 
empty revisions to keep the revisions the same, so I end up with 
repositories like


/svn_data/repo/project_A:

 /
   /project_A
 /trunk
 /branches
 /tags

/svn_data/repo/project_B:

 /
   /project_B
 /trunk
 /branches
 /tags

  If I add something to my apache conf like 'SVNParentPath 
/svn_data/repo', but this leads to URLs that end with 
'project_A/project_A' (since 'project_A' is the root directory of the 
repository).  If I try to modify my dump/load script to modify the path 
to drop 'project_A' then that breaks everyone's workspace.


  Is there any approach I can take to break up repositories and keep 
workspaces intact?  Does anyone have experience with breaking up a 
repository like this?


--Mattius McLaughlin

Re: ubdefined reference error with v1.7.3

2012-03-01 Thread Philip Martin 
"Ravish Nayak S. R."  writes:

> I am trying to build/install subversion 1.7.3 on 
> rhe4-x86_64 platform, I come across with below error and I could able to
>  move further..
>
> ~/subv/subversion/libsvn_repos/.libs/libsvn_repos-1.so.0: undefined reference 
> to `svn_txdelta_to_svndiff2'
>
> ~/subv/subversion/libsvn_ra/.libs/libsvn_ra-1.so: undefined reference to 
> `svn_compat_wrap_file_rev_handler'
>
> ~/subv//subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.so.0: undefined 
> reference to `svn_txdelta_stream_create'
>
> In
>  the same forum I saw that one of the user gave solution saying it is 
> looking for old svn(1.6) libraries try to delete old.. But in my case 
> there is no old subversion libraries..

In which directories did you look?  Those symbols are present in 1.4 so
you are looking for Subversion 1.3 or earlier.

Are you building from a tarball?  Are you using the libtool that came
with the tarball or did you run autogen.sh?  Do you have any special
settings such as LD_LIBRARY_PATH or ld.so.conf?  What configure command
did you use?  What is the exact link command that is failing?

-- 
Philip

Re: Best approach to break up a repository

2012-03-01 Thread Ryan Schmidt 

On Mar 1, 2012, at 15:46, Mattius McLaughlin wrote:

> I'd like to break each of those projects into separate repositories.  Given 
> the number of designers we have, it's a bit unreasonable to expect everyone 
> to recreate every workspace so I'd like to keep all URLs the same.

There's no choice; when you split the big repository into smaller repositories, 
each repository must be given its own UUID (Universally Unique IDentifier), 
different from the big repository's UUID. A working copy is matched to a 
particular repository by UUID. Once you have new repositories, you must check 
out new working copies. No exceptions.


> So I'd like to have repositories at /svn_data/repo/project_A, 
> /svn_data/repo/project_B, /svn_data/repo/project_C, etc.  I've written 
> something that can dump/load each one of the projects above and add empty 
> revisions to keep the revisions the same, so I end up with repositories like
> 
> /svn_data/repo/project_A:
> 
> /
>   /project_A
> /trunk
> /branches
> /tags
> 
> /svn_data/repo/project_B:
> 
> /
>   /project_B
> /trunk
> /branches
> /tags
> 
>  If I add something to my apache conf like 'SVNParentPath /svn_data/repo', 
> but this leads to URLs that end with 'project_A/project_A' (since 'project_A' 
> is the root directory of the repository).  If I try to modify my dump/load 
> script to modify the path to drop 'project_A' then that breaks everyone's 
> workspace.

Everyone's working copy is already broken by splitting the repository, so you 
may as well rearrange. svndumptool can help, or you can simply "svn mv" things 
into place.