date:20120319

Daniel Shahaf danie...@elego.de writes:

 From what is there so far, yes. We do have different operations
 occurring at the same time, but for these ones, I see MERGE and DELETE
 verbs overlapping in the same or near time intervals according to the
 Apache logs. I just did a quick look in the Apache logs during a time
 window where the bug wasn't triggered, and was able to see cases where
 I have the following:
  rev(x-1) merge
  rev(x) merge
  rev(x) delete
  rev(x-1) delete
 
 This seems fine.
 The case that I had seen in my reported cases are as follows:
  rev(x-1) merge
  rev(x) merge
  rev(x-1) delete
  rev(x) delete
 

 I have tried forcing this sequence in the debugger, but that did not
 reproduce the bug.

[...]

 I conclude that the specific MERGE/MERGE/DELETE/DELETE order, by itself,
 is not sufficient to reproduce the bug.

DELETE is extremely unlikely to be involved in this bug.  mod_dav_svn
maintains a mapping of DAV activity ID to Subversion transaction name in
the dav/ subdirectory of a repository.  The dav/ subdirectory is not
part of the Subversion filesystem.  DELETE is used to remove the mapping
for a particular activity ID and to remove the transaction if it still
exists.  Following a successful MERGE the transaction will have been
converted into a revision so DELETE has no effect on the the Subversion
filesystem.  DELETE will only affect the Subversion filesystem if called
before a successful MERGE, and that will cause any subsequent MERGE for
the activity to fail.

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

Re: Restore SVN server from files

2012-03-19 Thread Nico Kadel-Garcia

On Mon, Mar 19, 2012 at 3:59 AM, Alin ILIE alin.i...@yellowgnu.net wrote:

 The backup transfer to a different machine did not worked, and I didn't
 notice this. :(

 Got it !
 1) Install SVN on a new linux server
 2) Configure SVN
 3) Place the files recovered in the place where I defined repositories
 home in the step 2
 4) If I will change the server URL, I have to run svn relocate or svn
 switch --relocate according to the version that I will have on the new
 server.

 MANY THANKS,
 Alin

And just as with a backup, you'll need to restore the *access control* you
had before, which is usually not stored within the SVN
directories themselves.  SSH public keys for svn+ssh, daemon configurations
for svnserve, Apache configs for HTTPS, and file ownership would need to be
set up. These are the same factors that need to be preserved, usually out
of band, for a backup or remote svnsync based mirror.

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

Daniel Shahaf wrote on Sun, Mar 18, 2012 at 16:28:21 +0200:
 [ cc += dev@. summary for dev@: investigating issue #4129: predecessor
 count of rN is not incremented by one wrt that of r(N-1); see 
 http://subversion.tigris.org/issues/show_bug.cgi?id=4129 ]

Okay, count me happy :-)  I can reproduce this:

[[[
$SVN ps svn:mergeinfo '/branch/A:2' wc1/trunk/A
$SVN ps svn:mergeinfo '/branch/iota:2' wc2/trunk/iota
$SVN mkdir wc1/foo
$SVN mkdir wc2/bar
$svn ci -mm wc1  $svn ci -mm wc2  wait
]]]

Output:
[[[
Adding wc1/foo
Sendingwc1/trunk/A
Adding wc2/bar
Sendingwc2/trunk/iota

Committed revision 2.
subversion/svn/commit-cmd.c:183: (apr_err=160004)
subversion/libsvn_client/commit.c:876: (apr_err=160004)
subversion/libsvn_client/commit.c:876: (apr_err=160004)
svn: E160004: Commit failed (details follow):
subversion/libsvn_ra_serf/commit.c:2216: (apr_err=160004)
subversion/libsvn_ra_serf/commit.c:2216: (apr_err=160004)
subversion/libsvn_ra_serf/commit.c:2216: (apr_err=160004)
subversion/libsvn_ra_serf/util.c:774: (apr_err=160004)
subversion/libsvn_ra_serf/util.c:2087: (apr_err=160004)
subversion/libsvn_ra_serf/util.c:2087: (apr_err=160004)
subversion/libsvn_ra_serf/util.c:920: (apr_err=160004)
svn: E160004: predecessor count for the root node-revision is wrong: found (2+1 
!= 2), committing r3
]]]

Error log:
[[[
[Mon Mar 19 14:19:41.388413 2012] [dav:error] [pid 17156:tid 3064073072] 
[client ::1:40969] Could not MERGE resource /t/r1/!svn/txn/1-2 into /t/r1.  
[409, #0]
[Mon Mar 19 14:19:41.388497 2012] [dav:error] [pid 17156:tid 3064073072] 
[client ::1:40969] An error occurred while committing the transaction.  [409, 
#160004]
[Mon Mar 19 14:19:41.388518 2012] [dav:error] [pid 17156:tid 3064073072] 
[client ::1:40969] predecessor count for the root node-revision is wrong: found 
(2+1 != 2), committing r3  [409, #160004]
[Mon Mar 19 14:19:42.024052 2012] [authz_core:debug] [pid 17156:tid 3055680368] 
mod_authz_core.c(783): [client ::1:40971] AH01626: authorization result of 
Require all granted: granted
[Mon Mar 19 14:19:42.024114 2012] [authz_core:debug] [pid 17156:tid 3055680368] 
mod_authz_core.c(783): [client ::1:40971] AH01626: authorization result of 
RequireAny: granted
[Mon Mar 19 14:19:42.024781 2012] [dav:error] [pid 17156:tid 3055680368] 
[client ::1:40971] Could not fetch resource information.  [404, #0]
[Mon Mar 19 14:19:42.024820 2012] [dav:error] [pid 17156:tid 3055680368] 
[client ::1:40971] Named transaction doesn't exist.  [404, #0]
]]]

Using another property, or omitting either propset, is enough to cause
the bug not to trigger.


The bug reproduced both with and without the following patch:
[[[
--- subversion/libsvn_fs_fs/tree.c  (revision 1301511)
+++ subversion/libsvn_fs_fs/tree.c  (working copy)
@@ -1 +1,2 @@
+#include unistd.h
 /* tree.c : tree-like filesystem, built on DAG filesystem
@@ -1701 +1702,2 @@ svn_fs_fs__commit_txn(const char **conflict_p,
+  sleep(3);
   err = svn_fs_fs__commit(new_rev, fs, txn, iterpool);
@@ -1729,3 +1731,4 @@ svn_fs_fs__commit_txn(const char **conflict_p,
  cleanup:
 
+  sleep(3);
   svn_fs_fs__reset_txn_caches(fs);
]]]


The bug reproduced with either ServerLimit 1 or ThreadLimit 1 in
httpd.conf.  (That forced both commits to be served by the same process
(resp., by different processes).)  I use httpd 2.4.1 with event MPM.

AW: a simple recipe to 'obliterate' an item from svn repository

2012-03-19 Thread Markus Schaber

Hi, Giorgio,

Maybe svndumpfilter can help:
http://svnbook.spears.at/nightly/de/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svndumpfilter
http://svnbook.spears.at/nightly/de/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering

Best regards

Markus Schaber
--
___
We software Automation.

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

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

-Ursprüngliche Nachricht-
Von: Giorgio F. Signorini [mailto:giorgio.signor...@unifi.it]
Gesendet: Freitag, 16. März 2012 19:33
An: users@subversion.apache.org
Betreff: a simple recipe to 'obliterate' an item from svn repository

Hello

I need to delete a file permanently from my repository, since it was added by
mistake and is very big. I understand this is not a very easy thing to do, and
is related to the project of an 'svn obliterate'
command.

I seem to have found a simple workaround for my problem, and I would very much
like to share it for comments.

Suppose the current revision is 200 and the big file was added in rev 100. I
can use the dump / load scheme of svnadmin, taking care in skipping revision
100 during the process:

svnadmin dump -r1:99 oldrepos rev.1-99 svnadmin dump -r101:200 --incremental
oldrepos rev.101-200

svnadmin create newrepos
svnadmin load newrepos rev.1-99
svnadmin load newrepos rev.101-200

I only wonder if the --incremental option will work even when merging
non-contiguous revisions. Please note that in revision 100 only the big
unwanted file was added.

Thank you for your help

-- GFS

Dr. Giorgio F. SIGNORINI, PhD
Dipartimento di Chimica tel: +39-055-457-3085
Universita` di Firenze
via della Lastruccia, 3 email: giorgio.signorini at unifi.it
I-50019 Sesto F. (Firenze) Italyhttp://www.chim.unifi.it/~signo
My PGP key: http://srv.chim.unifi.it/~signo/signo.asc

Reintegrate woes

2012-03-19 Thread Tennebø Frode

We have been working for a long time (almost a year) on two products in 
paralell.  One is a maintenance product, i.e. general bug fixes and very little 
new features, called base and is effectively trunk.  The other is a new and 
improved with all the latest bells and whistles, and is handled in a branch.  
Both of them are divided into ca. 80 sub-products, 10% unique and 90% common, 
of which roughly 20% of the latter are branched.

As both teams progressed they fixed bugs or added features in their respective 
product, hence it was necessary to merge both from branches to trunk and vice 
versa.

Now comes the time to merge branches back to trunk and I try with a:

ft@halt:/proj/.../ecom_spusvn merge --reintegrate 
file:///home10/svn/.../ecom_spu/branches/foo .

Sometimes this works as expected, but on most occasions I get:

svn: Reintegrate can only be used if revisions 1413 through 2204 were 
previously merged from file:///home10/svn/.../ecom_spu/trunk to the reintegrate 
source, but this is not the case:
  ecom_spu/branches/foo
Missing ranges: ecom_spu/trunk:1413-1707,1709-1852,1854-1855

I take it that meas that svn has detected that something has gone from branches 
back to trunk on an earlier occasion?  Isn't it really necessarry to break 
reintegrate like this?  svn has all the relevant information of which 
revisions have gone where.  And I can perform the merge by doing:

ft@halt:/proj/.../ecom_spusvn merge -r 1413:2204 
file:///home10/svn/...ecom_spu/branches/foo .
--- Merging r1414 through r1422 into '.':
Uecom_edhipc_decl.ads
Umtt_gateway.adb
--- Merging r1424 through r1527 into '.':
Gecom_edhipc_decl.ads
Gmtt_gateway.adb
--- Merging r1597 through r2204 into '.':
Uecom_spu_1.adb
Uecom_spu_socket.ads
Gecom_edhipc_decl.ads
Uecom_spu_socket.adb
Gmtt_gateway.adb

Or am I missing something here?

Regards,
 -Frode
-- 
^ Frode Tennebø   | email: frode.tenn...@saabgroup.com ^
| Saab Technologies Norway AS | Isebakkeveien 49   |
| N-1788 Halden   | Phone: +47 45 24 99 39 |
| with Standard.Disclaimer; use Standard.Disclaimer;   |

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

Daniel Shahaf danie...@elego.de writes:

 The bug reproduced with either ServerLimit 1 or ThreadLimit 1 in
 httpd.conf.  (That forced both commits to be served by the same process
 (resp., by different processes).)  I use httpd 2.4.1 with event MPM.

I can reproduce ove ra_local:

svnadmin create repo
svn mkdir -mm file://`pwd`/repo/A
svn mkdir -mm file://`pwd`/repo/B
svn co file://`pwd`/repo wc1
svn co file://`pwd`/repo wc2
svn ps svn:mergeinfo /P:2 wc1/A
svn ps svn:mergeinfo /Q:2 wc2/B
svn mkdir wc1/X
svn mkdir wc2/Y
svn ci -mm wc1  svn ci -mm wc2  wait

Gives:

Sendingwc1/A
Adding wc1/X
Sendingwc2/B
Adding wc2/Y

Committed revision 3.
svn: E160004: Commit failed (details follow):
svn: E160004: predecessor count for the root node-revision is wrong: found 3, 
committing r4

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

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

shashank subramaniam wrote on Mon, Mar 19, 2012 at 20:29:47 +0530:
 Hey,
  We tried looping as a solution to the ''Predescessor
 Count for the root node revision is wrong' error (We looped the commit
 alone till it is commited).This works, but if 100 people try to commit to
 the same repository at the same time, the 100th guy's instance of the
 program is looped 100 times.There is also the possibility of it falling
 into an infinite loop due to some internal error.So, can you suggest some
 other solution around this bug, whereby multiple users are able to commit
 to the same repository at the same time(Space complexity is not
 a constraint)
 

Normally concurrent commits are supported.  The bug under discussion has
to do with a flaw in the mechanism that causes concurrent commits to
succeed.

 I noticed a similar problem also, which I think might be related to the
 'Predescessor' bug. Simultaneous SVN Updates from the same repository by
 different users fails silently (throws no error, but update doesn't
 happen). I think, probably an implicit lock is being put on the repository,
 preventing simultaneous operations.Please do let us know if some solution
 exists.
 

In FSFS there are no read locks, and different readers don't interfere
with each other or with others.  You'll have to describe what you see in
more detail.  (Exactly what you did, what you saw, and how it differed
from what you expected to see)

Thanks

Daniel


 Thanks
 Subu

Quirk with svn:ignore

I ran into an unexpected behavior with svn:ignore today and wanted to see
if someone can verify whether this is a bug (in the current version) or
just an aspect of how Subversion works. We're still on 1.6x.

Given a tree with

trunk
   + cache
   + htdocs
   + logs
   + system

I have tried putting

cd trunk
svn propset svn:ignore logs/* .

...ignore everything in the *logs* directory, but the svn:ignore propset is
on *trunk*.
 This doesn't work -- that is, log files are not ignored as expected, but
shown as new files when running the project and svn status

However,

cd logs
svn propset svn:ignore * .

...setting svn:ignore * on logs, works.


For what it's worth, externals works fine this way, e.g.

cd trunk
svn propset svn:externals some/arbitrary/directory
http://svn-server/repo/folder .

// some/arbitrary/directory is created from the externally referenced
svn-server/repo/folder as expected

We were hoping to set all our externals and ignores on the trunk level
rather than sprinkling them throughout our project, but it doesn't seem
possible.

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: Quirk with svn:ignore

2012-03-19 Thread Giulio Troccoli




On 19/03/12 16:26, Geoff Hoffman wrote:
I ran into an unexpected behavior with svn:ignore today and wanted to 
see if someone can verify whether this is a bug (in the current 
version) or just an aspect of how Subversion works. We're still on 1.6x.


Given a tree with

trunk
   + cache
   + htdocs
   + logs
   + system

I have tried putting

cd trunk
svn propset svn:ignore logs/* .

...ignore everything in the /logs/ directory, but the svn:ignore 
propset is on /trunk/.
 This doesn't work -- that is, log files are not ignored as expected, 
but shown as new files when running the project and svn status




Do you mean that the files are shown with an A in the first column? If 
so, I don't think Subversion should ignore something that has been 
specifically added. Try to revert the addition, svn revert --depth 
infinity logs, and then set the svn:ignore property again.


Giulio

Re: Reintegrate woes

2012-03-19 Thread Stefan Sperling

On Mon, Mar 19, 2012 at 03:26:37PM +, Tennebø Frode wrote:
We have been working for a long time (almost a year) on two products in
paralell. One is a maintenance product, i.e. general bug fixes and very
little new features, called base and is effectively trunk. The other is a
new and improved with all the latest bells and whistles, and is handled in
a branch. Both of them are divided into ca. 80 sub-products, 10% unique and
90% common, of which roughly 20% of the latter are branched.

As both teams progressed they fixed bugs or added features in their
respective product, hence it was necessary to merge both from branches to
trunk and vice versa.

Now comes the time to merge branches back to trunk and I try with a:

ft@halt:/proj/.../ecom_spusvn merge --reintegrate
file:///home10/svn/.../ecom_spu/branches/foo .

Sometimes this works as expected, but on most occasions I get:

svn: Reintegrate can only be used if revisions 1413 through 2204 were
previously merged from file:///home10/svn/.../ecom_spu/trunk to the
reintegrate source, but this is not the case:
ecom_spu/branches/foo
Missing ranges: ecom_spu/trunk:1413-1707,1709-1852,1854-1855

I take it that meas that svn has detected that something has gone from
branches back to trunk on an earlier occasion? Isn't it really necessarry to
break reintegrate like this? svn has all the relevant information of which
revisions have gone where. And I can perform the merge by doing:

ft@halt:/proj/.../ecom_spusvn merge -r 1413:2204
file:///home10/svn/...ecom_spu/branches/foo .
--- Merging r1414 through r1422 into '.':
Uecom_edhipc_decl.ads
Umtt_gateway.adb
--- Merging r1424 through r1527 into '.':
Gecom_edhipc_decl.ads
Gmtt_gateway.adb
--- Merging r1597 through r2204 into '.':
Uecom_spu_1.adb
Uecom_spu_socket.ads
Gecom_edhipc_decl.ads
Uecom_spu_socket.adb
Gmtt_gateway.adb

Or am I missing something here?

See
http://mail-archives.apache.org/mod_mbox/subversion-dev/201107.mbox/%3c20110720124721.ga7...@ted.stsp.name%3E
and for more in-depth details and current developments see
http://wiki.apache.org/subversion/SymmetricMerge

Re: Quirk with svn:ignore

2012-03-19 Thread Andy Levy

On Mon, Mar 19, 2012 at 12:26, Geoff Hoffman ghoff...@cardinalpath.com wrote:
 I ran into an unexpected behavior with svn:ignore today and wanted to see if
 someone can verify whether this is a bug (in the current version) or just an
 aspect of how Subversion works. We're still on 1.6x.

 Given a tree with

 trunk
    + cache
    + htdocs
    + logs
    + system

 I have tried putting

 cd trunk
 svn propset svn:ignore logs/* .

 ...ignore everything in the logs directory, but the svn:ignore propset is on
 trunk.
  This doesn't work -- that is, log files are not ignored as expected, but
 shown as new files when running the project and svn status

 However,

 cd logs
 svn propset svn:ignore * .

 ...setting svn:ignore * on logs, works.

In the first example, your shell is expanding logs/* to a list of
all the items in that directory, and svn dutifully sets the property
on the current directory (.) to that (very long) value.

Re: Quirk with svn:ignore

2012-03-19 Thread Mark Phippard

On Mon, Mar 19, 2012 at 12:26 PM, Geoff Hoffman
ghoff...@cardinalpath.com wrote:
 I ran into an unexpected behavior with svn:ignore today and wanted to see if
 someone can verify whether this is a bug (in the current version) or just an
 aspect of how Subversion works. We're still on 1.6x.

 Given a tree with

 trunk
    + cache
    + htdocs
    + logs
    + system

 I have tried putting

 cd trunk
 svn propset svn:ignore logs/* .

 ...ignore everything in the logs directory, but the svn:ignore propset is on
 trunk.
  This doesn't work -- that is, log files are not ignored as expected, but
 shown as new files when running the project and svn status

 However,

 cd logs
 svn propset svn:ignore * .

 ...setting svn:ignore * on logs, works.

That is exactly how the feature is supposed to work.  Described in book here:

http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html


-- 
Thanks

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

Re: Quirk with svn:ignore

On Mon, Mar 19, 2012 at 9:32 AM, Giulio Troccoli 
giulio.trocc...@mediatelgroup.co.uk wrote:

 Do you mean that the files are shown with an A in the first column?


No, they're shown as

? logs/error.log
? logs/access.log

But they're not automagically ignored, even though they match logs/*
which successfully is applied as an svn:ignore pattern on trunk.



On Mon, Mar 19, 2012 at 9:35 AM, Mark Phippard markp...@gmail.com wrote:

 That is exactly how the feature is supposed to work.  Described in book
 here:

 http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html



Mark, I believe you, however I don't see which part of the docs you link to
addresses this case...

This part:

*
 Matches any string of characters, including the empty string



indicates it should work regardless where it's used.


And this part:

[image: [Tip]]

 Even if svn:ignore is set, you may run into problems if you use shell
 wildcards in a command. Shell wildcards are expanded into an explicit list
 of targets before Subversion operates on them, so running *svn SUBCOMMAND
  ** is just like running *svn SUBCOMMAND file1 file2 file3*


indicates that even cd logs  svn propset svn:ignore * .  should fail if
there are no files inside of logs, correct? But it doesn't fail it works in
that case.

It seems to me that if my shell is indeed expanding asterisk character to a
list of files to ignore, then ignore * on logs should fail similarly until
explicit files are there to pass to svn:ignore command.

I'm attempting to ignore all future files  folders, *, inside a folder
that is empty, before any files exist inside it. It's always worked for me
just putting ignore * on logs folder directly, I just never tried putting
it one level up before and was kind of confused as to why it didn't work.

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: Quirk with svn:ignore

2012-03-19 Thread Mark Phippard

On Mon, Mar 19, 2012 at 1:11 PM, Geoff Hoffman ghoff...@cardinalpath.comwrote:


 Mark, I believe you, however I don't see which part of the docs you link
 to addresses this case...


This part:

When found on a versioned directory, the svn:ignore property is expected to
contain a list of newline-delimited file patterns that Subversion should
use to determine ignorable objects in that same directory.

-- 
Thanks

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

Re: Quirk with svn:ignore

Ahhh Rats.  Thanks I missed that.


On Mon, Mar 19, 2012 at 10:13 AM, Mark Phippard markp...@gmail.com wrote:

 in that same directory.

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: Quirk with svn:ignore

2012-03-19 Thread Giulio Troccoli




On 19/03/12 17:11, Geoff Hoffman wrote:




On Mon, Mar 19, 2012 at 9:32 AM, Giulio Troccoli 
giulio.trocc...@mediatelgroup.co.uk 
mailto:giulio.trocc...@mediatelgroup.co.uk wrote:


Do you mean that the files are shown with an A in the first column?


No, they're shown as

? logs/error.log
? logs/access.log

But they're not automagically ignored, even though they match logs/* 
which successfully is applied as an svn:ignore pattern on trunk.





Ok, have you tried ignoring just logs rather than all files, I mean svn 
ps svn:ignore logs ? As Andy said, the * is expanded by your shell, so 
basically you won't ignore future logs.


G

Re: Quirk with svn:ignore

On Mon, Mar 19, 2012 at 10:16 AM, Giulio Troccoli 
giulio.trocc...@mediatelgroup.co.uk wrote:



 On 19/03/12 17:11, Geoff Hoffman wrote:




 On Mon, Mar 19, 2012 at 9:32 AM, Giulio Troccoli 
 giulio.trocc...@mediatelgroup.co.uk wrote:

 Do you mean that the files are shown with an A in the first column?


  No, they're shown as

  ? logs/error.log
 ? logs/access.log

  But they're not automagically ignored, even though they match logs/*
 which successfully is applied as an svn:ignore pattern on trunk.



 Ok, have you tried ignoring just logs rather than all files, I mean svn
 ps svn:ignore logs ? As Andy said, the * is expanded by your shell, so
 basically you won't ignore future logs.

 G



Yeah, Mark's right. svn:ignore is not designed to work anywhere other than
the current directory. :-/

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

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

Philip Martin philip.mar...@wandisco.com writes:

 I can reproduce ove ra_local:

 svnadmin create repo
 svn mkdir -mm file://`pwd`/repo/A
 svn mkdir -mm file://`pwd`/repo/B
 svn co file://`pwd`/repo wc1
 svn co file://`pwd`/repo wc2
 svn ps svn:mergeinfo /P:2 wc1/A
 svn ps svn:mergeinfo /Q:2 wc2/B
 svn mkdir wc1/X
 svn mkdir wc2/Y
 svn ci -mm wc1  svn ci -mm wc2  wait

 Gives:

 Sendingwc1/A
 Adding wc1/X
 Sendingwc2/B
 Adding wc2/Y

 Committed revision 3.
 svn: E160004: Commit failed (details follow):
 svn: E160004: predecessor count for the root node-revision is wrong: found 3, 
 committing r4

This is the problem code in libsvn_fs_fs/tree.c:merge

  SVN_ERR(svn_fs_fs__dag_get_predecessor_count(pred_count, source, pool));
  SVN_ERR(update_ancestry(fs, source_id, target_id, target_path,
  pred_count, pool));

  if (svn_fs_fs__fs_supports_mergeinfo(fs))
SVN_ERR(svn_fs_fs__dag_increment_mergeinfo_count(target,
 mergeinfo_increment,
 pool));


target is dag_node_t* which is opaque outside dag.c and
target-node_revision-predecessor_count is 3 when we reach the above
code.

update_ancestry rewrites the file repo/db/transactions/2-2.txn/node.0.0
with the correctly updated value count: 4 but nothing updates
target-node_revision-predecessor_count in memory.

svn_fs_fs__dag_increment_mergeinfo_count then rewrites 
repo/db/transactions/2-2.txn/node.0.0
pulling the old value of target-node_revision-predecessor_count from
memory and putting count: 3 back in the file.

If I use the debugger to manually set target-node_revision to NULL
inside svn_fs_fs__dag_increment_mergeinfo_count then the commit works.
I'm not exactly sure how all the FSFS caching layers are supposed to
interact.  Is tree.c:update_ancestry supposed to update the in-memory
predecessor_count?  Should there be a svn_fs_fs__dag_xxx function to
change the predecessor count?  Should target-node_revision be set to
NULL soemwehere?  Something else?

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

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

Philip Martin wrote on Mon, Mar 19, 2012 at 17:25:22 +:
 Philip Martin philip.mar...@wandisco.com writes:
 
  I can reproduce ove ra_local:
 
  svnadmin create repo
  svn mkdir -mm file://`pwd`/repo/A
  svn mkdir -mm file://`pwd`/repo/B
  svn co file://`pwd`/repo wc1
  svn co file://`pwd`/repo wc2
  svn ps svn:mergeinfo /P:2 wc1/A
  svn ps svn:mergeinfo /Q:2 wc2/B
  svn mkdir wc1/X
  svn mkdir wc2/Y
  svn ci -mm wc1  svn ci -mm wc2  wait
 
  Gives:
 
  Sendingwc1/A
  Adding wc1/X
  Sendingwc2/B
  Adding wc2/Y
 
  Committed revision 3.
  svn: E160004: Commit failed (details follow):
  svn: E160004: predecessor count for the root node-revision is wrong: found 
  3, committing r4
 
 This is the problem code in libsvn_fs_fs/tree.c:merge
 
   SVN_ERR(svn_fs_fs__dag_get_predecessor_count(pred_count, source, pool));
   SVN_ERR(update_ancestry(fs, source_id, target_id, target_path,
   pred_count, pool));
 
   if (svn_fs_fs__fs_supports_mergeinfo(fs))
 SVN_ERR(svn_fs_fs__dag_increment_mergeinfo_count(target,
  mergeinfo_increment,
  pool));
 
 
 target is dag_node_t* which is opaque outside dag.c and
 target-node_revision-predecessor_count is 3 when we reach the above
 code.
 
 update_ancestry rewrites the file repo/db/transactions/2-2.txn/node.0.0
 with the correctly updated value count: 4 but nothing updates
 target-node_revision-predecessor_count in memory.
 
 svn_fs_fs__dag_increment_mergeinfo_count then rewrites 
 repo/db/transactions/2-2.txn/node.0.0
 pulling the old value of target-node_revision-predecessor_count from
 memory and putting count: 3 back in the file.
 
 If I use the debugger to manually set target-node_revision to NULL
 inside svn_fs_fs__dag_increment_mergeinfo_count then the commit works.
 I'm not exactly sure how all the FSFS caching layers are supposed to
 interact.  Is tree.c:update_ancestry supposed to update the in-memory
 predecessor_count?  Should there be a svn_fs_fs__dag_xxx function to
 change the predecessor count?  Should target-node_revision be set to
 NULL soemwehere?  Something else?

Just a note that another option here is for merge() to re-fetch
'dag_node_t *target' via dag.h APIs, to get another struct with a fresh
(actually: not yet populated) cache -noderev member.

Re: Quirk with svn:ignore

2012-03-19 Thread Ryan Schmidt


On Mar 19, 2012, at 12:16, Giulio Troccoli wrote:

 Ok, have you tried ignoring just logs rather than all files, I mean svn ps 
 svn:ignore logs ?

The logs directory has already been added and committed; telling Subversion to 
now ignore it will do nothing useful.

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

2012-03-19 Thread C. Michael Pilato

On 03/19/2012 01:25 PM, Philip Martin wrote:
 Philip Martin philip.mar...@wandisco.com writes:
 
 I can reproduce ove ra_local:

 svnadmin create repo
 svn mkdir -mm file://`pwd`/repo/A
 svn mkdir -mm file://`pwd`/repo/B
 svn co file://`pwd`/repo wc1
 svn co file://`pwd`/repo wc2
 svn ps svn:mergeinfo /P:2 wc1/A
 svn ps svn:mergeinfo /Q:2 wc2/B
 svn mkdir wc1/X
 svn mkdir wc2/Y
 svn ci -mm wc1  svn ci -mm wc2  wait

 Gives:

 Sendingwc1/A
 Adding wc1/X
 Sendingwc2/B
 Adding wc2/Y

 Committed revision 3.
 svn: E160004: Commit failed (details follow):
 svn: E160004: predecessor count for the root node-revision is wrong: found 
 3, committing r4

Is this problem specific to the FSFS backend?

-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

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

C. Michael Pilato wrote on Mon, Mar 19, 2012 at 13:57:51 -0400:
 Is this problem specific to the FSFS backend?

No.

% ../runpytest svnadmin mergeinfo_race --fs-type bdb
2012-03-19 20:21:44 [WARNING] CWD: 
/home/daniel/src/svn/t1/subversion/tests/cmdline
2012-03-19 20:21:44 [WARNING] EXCEPTION: Failure: one or both commits failed
XFAIL: svnadmin_tests.py 29: concurrent mergeinfo commits invalidate pred-count

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

C. Michael Pilato cmpil...@collab.net writes:

 On 03/19/2012 01:25 PM, Philip Martin wrote:
 Philip Martin philip.mar...@wandisco.com writes:
 
 I can reproduce ove ra_local:

 svnadmin create repo
 svn mkdir -mm file://`pwd`/repo/A
 svn mkdir -mm file://`pwd`/repo/B
 svn co file://`pwd`/repo wc1
 svn co file://`pwd`/repo wc2
 svn ps svn:mergeinfo /P:2 wc1/A
 svn ps svn:mergeinfo /Q:2 wc2/B
 svn mkdir wc1/X
 svn mkdir wc2/Y
 svn ci -mm wc1  svn ci -mm wc2  wait

 Gives:

 Sendingwc1/A
 Adding wc1/X
 Sendingwc2/B
 Adding wc2/Y

 Committed revision 3.
 svn: E160004: Commit failed (details follow):
 svn: E160004: predecessor count for the root node-revision is wrong: found 
 3, committing r4

 Is this problem specific to the FSFS backend?

Yes, I think it is.

For BDB the dag_node_t type in dag.c doesn't have a node_revision
member.  When update_ancestry does svn_fs_bdb__put_node_revision it
writes to the database and subsequent svn_fs_bdb__get_node_revision will
see the updated value.

For FSFS the svn_fs_fs__put_node_revision call writes to the
transactions subdir but the in-memory node_revision doesn't get changed.

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

Re: Quirk with svn:ignore

On Mon, Mar 19, 2012 at 10:50 AM, Ryan Schmidt 
subversion-20...@ryandesign.com wrote:


 On Mar 19, 2012, at 12:16, Giulio Troccoli wrote:

  Ok, have you tried ignoring just logs rather than all files, I mean svn
 ps svn:ignore logs ?

 The logs directory has already been added and committed; telling
 Subversion to now ignore it will do nothing useful.



Correct, Ryan.

Mark nailed it. Subversion can only ignore patterns set on the current
directory. Or, it doesn't traverse into subdirectories looking for files to
ignore, even if you specify a pattern with a directory separator in it...
even if it seems totally logical that it should, and even though it accepts
an ignore pattern with a directory separator in it.

-- 


This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

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

Daniel Shahaf danie...@elego.de writes:

 C. Michael Pilato wrote on Mon, Mar 19, 2012 at 13:57:51 -0400:
 Is this problem specific to the FSFS backend?

 No.

 % ../runpytest svnadmin mergeinfo_race --fs-type bdb
 2012-03-19 20:21:44 [WARNING] CWD: 
 /home/daniel/src/svn/t1/subversion/tests/cmdline
 2012-03-19 20:21:44 [WARNING] EXCEPTION: Failure: one or both commits failed
 XFAIL: svnadmin_tests.py 29: concurrent mergeinfo commits invalidate 
 pred-count

I think that's a failure of the regression test, after the XFAIL the
repository looks like:

$ svn log -vqr3:2 file://`pwd`/svn-test-work/repositories/svnadmin_tests-29/

r3 | jrandom | 2012-03-19 18:28:53 + (Mon, 19 Mar 2012)
Changed paths:
   M /A
   A /d1

r2 | jrandom | 2012-03-19 18:28:53 + (Mon, 19 Mar 2012)
Changed paths:
   A /d2
   M /iota


Also the test still XFAILs for FSFS with my FSFS patch to fix the
problem.

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

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

2012-03-19 Thread C. Michael Pilato

On 03/19/2012 02:24 PM, Philip Martin wrote:
 C. Michael Pilato cmpil...@collab.net writes:
 Is this problem specific to the FSFS backend?
 
 Yes, I think it is.
 
 For BDB the dag_node_t type in dag.c doesn't have a node_revision
 member.  When update_ancestry does svn_fs_bdb__put_node_revision it
 writes to the database and subsequent svn_fs_bdb__get_node_revision will
 see the updated value.
 
 For FSFS the svn_fs_fs__put_node_revision call writes to the
 transactions subdir but the in-memory node_revision doesn't get changed.

Gotcha.  Thanks for the response.

I remember when the BDB code had an in-memory node-revision structure and
tried to maintain that using the trail construct.  I remember also the day I
purged the code of that mess. :-)

-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

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

Philip Martin wrote on Mon, Mar 19, 2012 at 18:31:41 +:
 Daniel Shahaf danie...@elego.de writes:
 
  C. Michael Pilato wrote on Mon, Mar 19, 2012 at 13:57:51 -0400:
  Is this problem specific to the FSFS backend?
 
  No.
 
  % ../runpytest svnadmin mergeinfo_race --fs-type bdb
  2012-03-19 20:21:44 [WARNING] CWD: 
  /home/daniel/src/svn/t1/subversion/tests/cmdline
  2012-03-19 20:21:44 [WARNING] EXCEPTION: Failure: one or both commits failed
  XFAIL: svnadmin_tests.py 29: concurrent mergeinfo commits invalidate 
  pred-count
 
 I think that's a failure of the regression test, after the XFAIL the
 repository looks like:
 

Right as usual, implemented your fix in r1302591.

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

Philip Martin philip.mar...@wandisco.com writes:

 If I use the debugger to manually set target-node_revision to NULL
 inside svn_fs_fs__dag_increment_mergeinfo_count then the commit works.
 I'm not exactly sure how all the FSFS caching layers are supposed to
 interact.  Is tree.c:update_ancestry supposed to update the in-memory
 predecessor_count?  Should there be a svn_fs_fs__dag_xxx function to
 change the predecessor count?  Should target-node_revision be set to
 NULL soemwehere?  Something else?

Moving update_ancestry from tree.c to dag.c is one way to fix the
problem.  Daniel also suggested removing the node_revision member of
dag_node_t altogether and relying on new 1.7 caching to give us the
performance.  I suppose we would still need a patch like this for 1.6.


Index: ../src/subversion/libsvn_fs_fs/dag.c
===
--- ../src/subversion/libsvn_fs_fs/dag.c(revision 1302591)
+++ ../src/subversion/libsvn_fs_fs/dag.c(working copy)
@@ -1296,3 +1296,27 @@
 
   return SVN_NO_ERROR;
 }
+
+svn_error_t *
+svn_fs_fs__dag_update_ancestry(dag_node_t *target,
+   dag_node_t *source,
+   apr_pool_t *pool)
+{
+  node_revision_t *source_noderev, *target_noderev;
+
+  if (! svn_fs_fs__dag_check_mutable(target))
+return svn_error_createf
+  (SVN_ERR_FS_NOT_MUTABLE, NULL,
+   _(Attempted to update ancestry of non-mutable node));
+
+  SVN_ERR(get_node_revision(source_noderev, source, pool));
+  SVN_ERR(get_node_revision(target_noderev, target, pool));
+
+  target_noderev-predecessor_id = source-id;
+  target_noderev-predecessor_count = source_noderev-predecessor_count;
+  if (target_noderev-predecessor_count != -1)
+target_noderev-predecessor_count++;
+
+  return svn_fs_fs__put_node_revision(target-fs, target-id, target_noderev,
+  FALSE, pool);
+}
Index: ../src/subversion/libsvn_fs_fs/tree.c
===
--- ../src/subversion/libsvn_fs_fs/tree.c   (revision 1302591)
+++ ../src/subversion/libsvn_fs_fs/tree.c   (working copy)
@@ -1142,32 +1142,6 @@
 }
 
 
-/* Teach node-revision TARGET_ID that node-revision SOURCE_ID is its
-   predecessor.  TARGET_PATH is used for error messages only. */
-static svn_error_t *
-update_ancestry(svn_fs_t *fs,
-const svn_fs_id_t *source_id,
-const svn_fs_id_t *target_id,
-const char *target_path,
-int source_pred_count,
-apr_pool_t *pool)
-{
-  node_revision_t *noderev;
-
-  if (svn_fs_fs__id_txn_id(target_id) == NULL)
-return svn_error_createf
-  (SVN_ERR_FS_NOT_MUTABLE, NULL,
-   _(Unexpected immutable node at '%s'), target_path);
-
-  SVN_ERR(svn_fs_fs__get_node_revision(noderev, fs, target_id, pool));
-  noderev-predecessor_id = source_id;
-  noderev-predecessor_count = source_pred_count;
-  if (noderev-predecessor_count != -1)
-noderev-predecessor_count++;
-  return svn_fs_fs__put_node_revision(fs, target_id, noderev, FALSE, pool);
-}
-
-
 /* Set the contents of CONFLICT_PATH to PATH, and return an
SVN_ERR_FS_CONFLICT error that indicates that there was a conflict
at PATH.  Perform all allocations in POOL (except the allocation of
@@ -1219,7 +1193,6 @@
   apr_hash_index_t *hi;
   svn_fs_t *fs;
   apr_pool_t *iterpool;
-  int pred_count;
   apr_int64_t mergeinfo_increment = 0;
 
   /* Make sure everyone comes from the same filesystem. */
@@ -1543,9 +1516,7 @@
 }
   svn_pool_destroy(iterpool);
 
-  SVN_ERR(svn_fs_fs__dag_get_predecessor_count(pred_count, source, pool));
-  SVN_ERR(update_ancestry(fs, source_id, target_id, target_path,
-  pred_count, pool));
+  SVN_ERR(svn_fs_fs__dag_update_ancestry(target, source, pool));
 
   if (svn_fs_fs__fs_supports_mergeinfo(fs))
 SVN_ERR(svn_fs_fs__dag_increment_mergeinfo_count(target,
Index: ../src/subversion/libsvn_fs_fs/dag.h
===
--- ../src/subversion/libsvn_fs_fs/dag.h(revision 1302591)
+++ ../src/subversion/libsvn_fs_fs/dag.h(working copy)
@@ -603,6 +603,10 @@
   dag_node_t *node,
   apr_pool_t *pool);
 
+svn_error_t *
+svn_fs_fs__dag_update_ancestry(dag_node_t *target,
+   dag_node_t *source,
+   apr_pool_t *pool);
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */

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

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

Philip Martin wrote on Mon, Mar 19, 2012 at 18:45:37 +:
 Philip Martin philip.mar...@wandisco.com writes:
 
  If I use the debugger to manually set target-node_revision to NULL
  inside svn_fs_fs__dag_increment_mergeinfo_count then the commit works.
  I'm not exactly sure how all the FSFS caching layers are supposed to
  interact.  Is tree.c:update_ancestry supposed to update the in-memory
  predecessor_count?  Should there be a svn_fs_fs__dag_xxx function to
  change the predecessor count?  Should target-node_revision be set to
  NULL soemwehere?  Something else?
 
 Moving update_ancestry from tree.c to dag.c is one way to fix the
 problem.  Daniel also suggested removing the node_revision member of
 dag_node_t altogether and relying on new 1.7 caching to give us the
 performance.  I suppose we would still need a patch like this for 1.6.
 

++1

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

2012-03-19 Thread Jason Wong

Hello Daniel, Philip.

I have been following the thread: #4129 is reproducible Re:
predecessor count for the root node-revision is wrong message.
It looks like you all have it figured out now. Good job.

Do you need any more information from me at this point? Thanks.

Jason Wong.

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

Jason Wong wrote on Mon, Mar 19, 2012 at 13:41:19 -0700:
 Hello Daniel, Philip.
 
 I have been following the thread: #4129 is reproducible Re:
 predecessor count for the root node-revision is wrong message.
 It looks like you all have it figured out now. Good job.
 
 Do you need any more information from me at this point? Thanks.
 

Thanks Jason.  It would be useful if you could confirm that you do not
run into the error after rebuilding the server with r1302399 and
r1302613 applied.  (If you run the test suite, apply r1302539 and
r1302591 too.)  These revisions constitute the fix which is nominated
for inclusion in 1.6.18 and 1.7.5; see ^/subversion/branches/1.7.x/STATUS.

Cheers,

Daniel

 Jason Wong.

preventing commits (this is not a classic hook question)

2012-03-19 Thread Michael Hüttermann

Hello,

I'm wondering if there is any strategy for temporary preventing people
from committing to a svn repository, without the person who sets the hook
(or sth similar) being the admin of the svn repository. Thus, in this
case, there is no option to directly access the /hooks/ folder.

A poor man's option could be working with locks. But, recursively
locking a large repo path could be inefficient, and locks can be stolen
anyway. So it looks like the wrong approach from many perspectives.

Any idea for preventing commits, for a specific time, without being able
to directly accessing the hooks folder?

Thanks!!!

Michael

Re: preventing commits (this is not a classic hook question)

2012-03-19 Thread Les Mikesell

On Mon, Mar 19, 2012 at 4:06 PM, Michael Hüttermann
mich...@huettermann.net wrote:
 Hello,

 I'm wondering if there is any strategy for temporary preventing people
 from committing to a svn repository, without the person who sets the hook
 (or sth similar) being the admin of the svn repository. Thus, in this
 case, there is no option to directly access the /hooks/ folder.

 A poor man's option could be working with locks. But, recursively
 locking a large repo path could be inefficient, and locks can be stolen
 anyway. So it looks like the wrong approach from many perspectives.

 Any idea for preventing commits, for a specific time, without being able
 to directly accessing the hooks folder?

The hook script is a program that can access any data you want to make
available to it.  Maybe you should approach the question from the
other direction.  Who do you want to be able to control the setting,
and where can they store something that the hook script can check?

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

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

2012-03-19 Thread Jason Wong

On Mon, Mar 19, 2012 at 1:56 PM, Daniel Shahaf danie...@elego.de wrote:
 Jason Wong wrote on Mon, Mar 19, 2012 at 13:41:19 -0700:
 Hello Daniel, Philip.

 I have been following the thread: #4129 is reproducible Re:
 predecessor count for the root node-revision is wrong message.
 It looks like you all have it figured out now. Good job.

 Do you need any more information from me at this point? Thanks.


 Thanks Jason.  It would be useful if you could confirm that you do not
 run into the error after rebuilding the server with r1302399 and
 r1302613 applied.  (If you run the test suite, apply r1302539 and
 r1302591 too.)  These revisions constitute the fix which is nominated
 for inclusion in 1.6.18 and 1.7.5; see ^/subversion/branches/1.7.x/STATUS.


Hi Daniel.

The developer who built the svn client is away and will probably not be back
until later this week. What is your ETA for 1.7.5? Just wondering if that would
released before the developer I have is back.

Thanks.

Jason

 Cheers,

 Daniel

 Jason Wong.

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