Re: JavaHL bindings - post-commit error messages

[Martin Kutter]

On Wed, 17 Aug 2011 19:56:13 +0200, Martin Kutter
 wrote:
> Hi,
> 
> Am Dienstag, den 16.08.2011, 11:14 -0400 schrieb Mark Phippard:
>> On Tue, Aug 16, 2011 at 11:09 AM, Martin Kutter
>> wrote:
>> > is there a way to receive get post-commit error messages on
performing
>> > a
>> > commit with the JavaHL bindings?
>> 
>> Subclipse uses JavaHL and I believe it shows these messages.  Have you
>> registered a call back to receive the Notifications?
>> 
>>
http://subversion.apache.org/docs/javahl/1.6/org/tigris/subversion/javahl/Notify2.html
>> 

Subclipse does not show post-commit error messages (at least not ).

It also looks like JavaHL (1.6.17) does not transmit post-commit error
messages not even in notify callbacks.

Is this a bug?

Steps to reproduce:

1. Create svn repo with failing post-commit hook and output on stderr
2. Test with svn command line client, checkout, perform some change,
commit.
Expected output is like this:
D:\Martin\workspace\test>svn commit -m 'test'
Adding site

Committed revision 19.

Warning: post-commit hook failed (exit code 1) with output:
"Ausgabe auf STDERR"

3. make some change to the wc, and run the JUnit test below (with paths
changed to match your system)

Test fails, output is 

1.6.17 (r1128011)
Acttion: 17
ChangelistName: null
ContentState: 1
ErrMsg: null
Kind: 2
LockState: 1
MimeType: null
Path: D:/Martin/workspace/test/site
PathPrefix: D:/Martin/workspace
PropState: 1
Revision: -1
Lock: null
MergeRange: null
Source: D:/Martin/workspace/test/site
Commited revision: 18

Here's the test code:

package org.tigris.subversion.javahl;

import static org.junit.Assert.*;

import java.util.ArrayList;
import java.util.List;
import org.junit.Test;

public class SVNClientTest {

private List notifications = new
ArrayList();

@Test
public void testCommit() {
SVNClientInterface client = new SVNClient();
System.out.println(client.getVersion());
Notify2 notify = new Notify2() {

@Override
public void onNotify(NotifyInformation info) {
System.out.println("Acttion: " + 
info.getAction());
System.out.println("ChangelistName: " + 
info.getChangelistName());
System.out.println("ContentState: " + 
info.getContentState());
System.out.println("ErrMsg: " + 
info.getErrMsg());
System.out.println("Kind: " + info.getKind());
System.out.println("LockState: " + 
info.getLockState());
System.out.println("MimeType: " + 
info.getMimeType());
System.out.println("Path: " + info.getPath());
System.out.println("PathPrefix: " + 
info.getPathPrefix());
System.out.println("PropState: " + 
info.getPropState());
System.out.println("Revision: " + 
info.getRevision());
System.out.println("Lock: " + info.getLock());
System.out.println("MergeRange: " + 
info.getMergeRange());
System.out.println("Source: " + 
info.getSource());

notifications.add(info);
}
};

client.notification2(notify);

String[] paths = new String[] { "D:/Martin/workspace/test" };
String[] changeLists = new String[] {};
try {
long result = client.commit(paths, "test", 
Depth.infinity, false,
false, null, null);
if (result > 0) {
System.out.println("Commited revision: " + 
result);
}
} catch (ClientException e) {
e.printStackTrace();
}

List errors = new ArrayList();
for (NotifyInformation info : notifications) {
if (info.getErrMsg() != null)
errors.add(info.getErrMsg());
}
assertNotSame(0, errors.size());
}
}


Martin

svn log knows about svn:external

[rupert.thurner]

hi,

especially when continuous integration build one option to trigger the
build is if something changed. usually this is easy as the repo
version is increased. is there an easy way to find out if there is a
change considering svn:externals as well?

the only command i was aware of was svn log, but it seems not follow
externals. i also do not know a command which easily displays all
externals contained in a working copy ... which might be easier/
quicker to find out with the new wc format?

rupert.

Re: Tree Conflicts with Subversion 1.7

[Andreas Krey]

On Thu, 18 Aug 2011 20:46:51 +, Stefan Sperling wrote:
...
> > Actually I think these are better handled by throwing away the merge
> > results and doing the renames/removes on the respective branches, then
> > redo the merge.
> 
> The above is only for "add vs. add" situations.
> Scenarios involving renames are different.

I meant when I get an add/add conflict on unrelated directories
(or files), I'd undo the merge, rename one of the directories in the
respective branch and retry the merge. Offhand, I wouldn't know where
subversion would place the unrelated versions of the directories in the
sandbox, nor how I could tell it that I want one of those kept in the
merge result (with same or different name).

> > I tend to feel uneasy in these interactive conflict resolutions.
> 
> What makes you feel uneasy about it?

I'm used to manual merges, which means its always (p) with me. Which
unfortunately does not work quite well with properties, as far I
remember. (And (e) gives me 'EDITOR not set' even though it is
offered.) One thing that would be helpful is (!): Run a shell.
And in the interactive mode it's one file after another; I can't
compile well in between. (I was lucky enough not to have actual
tree conflicts yet.)

> Note that, ideally, this menu could be recalled offline, after the
> merge/update has completed with all conflicts postponed.
> So you'd have all the time in the world to figure out your answer,
> if that's what worrying you.

The problem is more like it is another tool which you hopefully never
need, yet need to know well if you do.

Just the display of what has been done so far ('dir from branch will
commit as newdir') is going to be interesting.

Andreas

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

Re: SlikSvn crash dump

[Andy Levy]

On Thu, Aug 18, 2011 at 10:51, Joel Hughes  wrote:
>
>

There is at least one known glitchy release of SlikSvn out there.

A crash dump is almost useless if there's no description of what you
were doing to make it happen. You can't just dump a logfile off to a
mailing list and expect something to be done with it.

This is better directed at the SlikSvn team, as they compile their own
binaries from the source distributed by this project.

svn upgrade: database table is locked

[Markus Schaber]

Hi,

Which circumstances can cause "svn upgrade" in SVN 1.7 to fail with the
following message:

svn: E200030: database table is locked: NODES

Thanks,

Best regards

Markus Schaber

___
We software Automation.

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

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

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

Re: Tree Conflicts with Subversion 1.7

[Stein Somers]

On 18-Aug-11 21:01, Stefan Sperling wrote:

Indeed, multiple copyfroms would be nasty.

But I don't see the need.


I definitely don't need it, I just saw a use in having it.

My idea that you should be able to choose the source was based on a wrong 
assumption. Now I realize merges are always asymmetric. Usually you commit a 
merge of branches A and B as a changeset in either A or B, but even if you 
commit as branch C, that changeset still starts off saying C is a copy of either 
A or B, with some more changes to it (right?). You always have to choose A or B, 
and you call one "local" and the other one "incoming" (by the way, I like those 
terms a lot better than the "mine" and "theirs" used in the interface - they 
freak me out when I merge "my" branch into "our" trunk).


That doesn't mean there is no case for wanting multiple copyfroms, if that is 
what Daniel Shahaf hints at, but just that the fact that "local" is favored is 
firmly part of svn's merge philosophy anyway, and I have no problem with that.


--
Stein

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

[Dennis Jones]

Anyone?  Really?  No one knows anything about this?

- Dennis

"Dennis Jones"  wrote in message 
news:j1shsm$lbu$1...@dough.gmane.org...
> Hi,
>
> I used rsvndump to dump a remote repository (because the server is running 
> an old version of SVN from before support for 'replay' was added).  Now I 
> am trying to load the dump file into my local repository (VisualSVN 2.1.9) 
> and I'm getting the following error:
>
>
> * adding path : trunk/SomePath/SomeFile.zip ...svnadmin: File already 
> exists: filesystem 'E:\Repositories\Archive\db', transaction '3186-2gi', 
> path 'trunk/SomePath/SomeFile.zip'
>
>
> Interestingly, it looks like it fails at revision 3186, but a glance at 
> the output shows:
>
> --- Committed revision 3186 >>>
>
> <<< Started new transaction, based on original revision 3187
>
> So why is the transaction for 3186 still there?
>
> This is my second attempt at doing this, and I got the same error (in the 
> same place) the first time.  The dump file is almost 5GB in size and the 
> dump takes about 3 days to complete, so I'm not keen on doing it again, 
> and I doubt it will help anyway.
>
> Of course, I started with an empty repository on the local server, so it's 
> not like it already had data in it.  So how can I get around this?
>
> Dennis
>
>
> 

Re: SlikSvn crash dump

[Andy Levy]

Please reply to all to keep discussion on the mailing list.

On Fri, Aug 19, 2011 at 07:48, Joel Hughes  wrote:
> Hey, I'm just following the directions provided when it happened. I thought
> it was pretty useless as well.  Perhaps instead you should provide a url
> which further explains all the details you would like and in what format.
>  The address provided for sending the dumps was generic so I figured it was
> automatically routing them and if I added more to the mail it would mess up
> the parsing and not get routed.
> I'll provide you a proper mail a little later.

Your first step in reporting an issue should be, unless you can
determine for certain that the source code hasn't been changed from
the official source, to report it to the maintainers of the particular
client you're using. And again, simply mailing a crash dump with no
additional information does not provide anyone with enough information
to help you.

The address you've sent the email to is neither "generic" nor
"automatically routed" - it is for discussion by & for users of
Subversion.

As I said before, there *have* been reports of problems with at least
one version of SlikSvn (see http://tinyurl.com/3tc2nss for references
to SlikSvn on this list), but since you've not posted what version
you're using, no one here can help you in that regard.

> On Fri, Aug 19, 2011 at 6:39 AM, Andy Levy  wrote:
>>
>> On Thu, Aug 18, 2011 at 10:51, Joel Hughes 
>> wrote:
>> >
>> >
>>
>> There is at least one known glitchy release of SlikSvn out there.
>>
>> A crash dump is almost useless if there's no description of what you
>> were doing to make it happen. You can't just dump a logfile off to a
>> mailing list and expect something to be done with it.
>>
>> This is better directed at the SlikSvn team, as they compile their own
>> binaries from the source distributed by this project.
>
>

Re: SlikSvn crash dump

[Mark Phippard]

On Fri, Aug 19, 2011 at 10:00 AM, Andy Levy  wrote:

> Please reply to all to keep discussion on the mailing list.
>
> On Fri, Aug 19, 2011 at 07:48, Joel Hughes 
> wrote:
> > Hey, I'm just following the directions provided when it happened. I
> thought
> > it was pretty useless as well.  Perhaps instead you should provide a url
> > which further explains all the details you would like and in what format.
> >  The address provided for sending the dumps was generic so I figured it
> was
> > automatically routing them and if I added more to the mail it would mess
> up
> > the parsing and not get routed.
> > I'll provide you a proper mail a little later.
>
> Your first step in reporting an issue should be, unless you can
> determine for certain that the source code hasn't been changed from
> the official source, to report it to the maintainers of the particular
> client you're using. And again, simply mailing a crash dump with no
> additional information does not provide anyone with enough information
> to help you.
>
> The address you've sent the email to is neither "generic" nor
> "automatically routed" - it is for discussion by & for users of
> Subversion.
>

The reporter does have a good point here.  The SVN devs should probably
setup a mailing list for crash dumps so that tools like SlikSVN that include
this facility can direct people to post their dumps to that list instead of
just sending them to users@.  I am sure when this code was originally added
there was an assumption the user would just know that the intent was for
them to compose an email with the problem.  That said, given how many
operating systems and other apps now include automated crash reporting I
think it is a reasonable assumption to assume that the software just wanted
you to send the dump.

-- 
Thanks

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

Merge symmetry (was: Tree Conflicts with Subversion 1.7)

[Andreas Krey]

On Fri, 19 Aug 2011 13:51:40 +, Stein Somers wrote:

> Now I realize merges are always asymmetric.

Actually, merging is a symmetric operation. The tree (and copyfrom
info) resulting from a merge should be the same independent of in
which direction the merge is performed. In svn the metadata just looks
completely different depending on the direction of the merge. (It also
is different due to the necessity of --reintegrate.)

Andreas

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

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

[Konstantin Kolinko]

2011/8/19 Dennis Jones :
> Anyone?  Really?  No one knows anything about this?
>
> - Dennis
>
> "Dennis Jones"  wrote in message
> news:j1shsm$lbu$1...@dough.gmane.org...
>> Hi,
>>
>> I used rsvndump to dump a remote repository (because the server is running
>> an old version of SVN from before support for 'replay' was added).  Now I
>> am trying to load the dump file into my local repository (VisualSVN 2.1.9)
>> and I'm getting the following error:
>>
>>
>>     * adding path : trunk/SomePath/SomeFile.zip ...svnadmin: File already
>> exists: filesystem 'E:\Repositories\Archive\db', transaction '3186-2gi',
>> path 'trunk/SomePath/SomeFile.zip'
>>
>>
>> Interestingly, it looks like it fails at revision 3186, but a glance at
>> the output shows:
>>
>> --- Committed revision 3186 >>>
>>
>> <<< Started new transaction, based on original revision 3187
>>
>> So why is the transaction for 3186 still there?
>>
>> This is my second attempt at doing this, and I got the same error (in the
>> same place) the first time.  The dump file is almost 5GB in size and the
>> dump takes about 3 days to complete, so I'm not keen on doing it again,
>> and I doubt it will help anyway.
>>
>> Of course, I started with an empty repository on the local server, so it's
>> not like it already had data in it.  So how can I get around this?
>>
>> Dennis
>>

>> I used rsvndump

What is that? You mean you performed the dump remotely using svnrdump
utility from some beta of svn 1.7 ? Does it work without replay
support on the server? (Isn't this utility essentially the same as
svnsync?)

I would suggest to compare what actually is in that revision in the
old and new repository. Do they match, or anything differs?

When you performed the dump, do you have read access to all paths in
the original repository?

Last time when I saw a message similar to yours was about a year ago,
when I tried to commit revision that had complicated moves and renames
/ replaces in it. The svn client (Tortoise) failed to commit it with a
similar message,  but when I rerun the operation it committed
successfully. I still do not know what the cause was -- maybe some
ordering between operations. (I am using HTTPS access protocol + neon
+ it was some version of 1.6 or 1.5 several months after release),

Best regards,
Konstantin Kolinko

Re: svn log knows about svn:external

[Konstantin Kolinko]

2011/8/19 rupert.thurner :
> hi,
>
> especially when continuous integration build one option to trigger the
> build is if something changed. usually this is easy as the repo
> version is increased. is there an easy way to find out if there is a
> change considering svn:externals as well?
>
> the only command i was aware of was svn log, but it seems not follow
> externals. i also do not know a command which easily displays all
> externals contained in a working copy ... which might be easier/
> quicker to find out with the new wc format?
>

Catch output of "svn up" into a file and see whether some changes are
mentioned in it. By the way, this command lists all externals as well.

If you want to trigger a build when something changes in repository -
use a post-commit hook at the svn server.  One option is to use the
hook to publish info into mailing list and watch that mailing list. ;)

Best regards,
Konstantin Kolinko

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

[Dennis Jones]

"Konstantin Kolinko"  wrote in message 
news:cabzhfvmz1acxa5vp2sbkctyezr8t3ih1xi2ogtsebyay3df...@mail.gmail.com...


>> I used rsvndump

> What is that? You mean you performed the dump remotely using svnrdump
> utility from some beta of svn 1.7 ? Does it work without replay
> support on the server? (Isn't this utility essentially the same as
> svnsync?)

No, I used "rsvndump", a third-party utility that I happened upon when 
googling for a way to dump a repository from an old server version <1.4.   I 
did try svnrdump from the 1.7 beta, but it (obviously) did not work because 
it requires the server to support replay.


> I would suggest to compare what actually is in that revision in the
> old and new repository. Do they match, or anything differs?

There is no new repository.  I am trying to create a new, clean repository 
from the old server (of which I only have remote access).


>
> When you performed the dump, do you have read access to all paths in
> the original repository?

Yes.


> Last time when I saw a message similar to yours was about a year ago,
> when I tried to commit revision that had complicated moves and renames
> / replaces in it. The svn client (Tortoise) failed to commit it with a
> similar message,  but when I rerun the operation it committed
> successfully. I still do not know what the cause was -- maybe some
> ordering between operations. (I am using HTTPS access protocol + neon
> + it was some version of 1.6 or 1.5 several months after release),

I've tried multiple times to re-run the operation.  It always fails at the 
same place.

- Dennis 

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

[Les Mikesell]

On 8/19/2011 11:20 AM, Dennis Jones wrote:




I would suggest to compare what actually is in that revision in the
old and new repository. Do they match, or anything differs?


There is no new repository.  I am trying to create a new, clean repository
from the old server (of which I only have remote access).


Your new, clean repository should have the contents up to the commit 
that failed.


But, it might be easier to use svnsync to do this.

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

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

[Stephen Butler]

On Aug 19, 2011, at 18:45 , Les Mikesell wrote:

> On 8/19/2011 11:20 AM, Dennis Jones wrote:
> 
>> 
>>> I would suggest to compare what actually is in that revision in the
>>> old and new repository. Do they match, or anything differs?
>> 
>> There is no new repository.  I am trying to create a new, clean repository
>> from the old server (of which I only have remote access).
> 
> Your new, clean repository should have the contents up to the commit that 
> failed.

Dennis,

You could compare the histories of the problematic file (and its parent
directories) in the two repositories.  I'll bet there's some moves and
replacements there, as Konstantin suggests.

Does rsvndump support moved/replaced items?  I'm sure it's not
trivial.

> 
> But, it might be easier to use svnsync to do this.

According to the original post, the old repository doesn't support svnsync.

Regards,
Steve

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

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

[Dennis Jones]

"Stephen Butler"  wrote in message 
news:e19fc591-322d-4775-8d5f-9bea8b791...@elego.de...

>On Aug 19, 2011, at 18:45 , Les Mikesell wrote:
>
>> On 8/19/2011 11:20 AM, Dennis Jones wrote:
>>
>>>
 I would suggest to compare what actually is in that revision in the
 old and new repository. Do they match, or anything differs?
>>>
>>> There is no new repository.  I am trying to create a new, clean 
>>> repository
>>> from the old server (of which I only have remote access).
>>
>> Your new, clean repository should have the contents up to the commit that 
>> failed.

Okay, then I will take a look and report back.


>You could compare the histories of the problematic file (and its parent
>directories) in the two repositories.  I'll bet there's some moves and
>replacements there, as Konstantin suggests.
>
>Does rsvndump support moved/replaced items?  I'm sure it's not
>trivial.

I would assume so.  I believe there are plenty of moves/branches/tags that 
occured prior to the revision where the error occurred.


>> But, it might be easier to use svnsync to do this.
>
>According to the original post, the old repository doesn't support svnsync.

That is correct.  The server is pre 1.4.

- Dennis 

Re: update in 1.6.17 slower?

[Ivan Zhakov]

On Fri, Aug 19, 2011 at 03:27, Seth Daniel
 wrote:
> Hello,
>
> Recently I upgraded from 1.6.9 to 1.6.17.  'svn up' is very noticeably
> slower than it used to be.  I didn't see anything in the CHANGES file
> about signficant 'update' changes so I was wondering if this was expected?
>
> With 1.6.9 I didn't turn off authz (even though I don't use it) but I
> thought maybe it was the problem with 1.6.17.  No luck.  (btw, I'm using
> Apache + https.  I turned *off* authz using SVNPathAuthz off).  checkout
> and other operations are very snappy.
>
> I am using default options when building subversion so I'm using neon.
> It's neon 0.25 (comes with Centos 5.4).
>
It could be related to the following change in Subversion 1.6.15:
[[
   * filter unreadable paths for 'svn ls' and 'svn co' (r997026, -070, -474)
]]

Log message for revision r997026  is:
[[[
For issue #3709 ("Inconsistency between "svn list" and "svn
checkout"), teach the mod_dav_svn tree walker logic to authorize
access to the paths it touches.

* subversion/mod_dav_svn/repos.c
 (do_walk): Replace a decade-old TODO about checking authorization on
   a directory's children with, you know, code that checks
   authorization on a directory's children.
]]]


-- 
Ivan Zhakov

BUG: Inconsistent handling of challenge-on-commit for conflicting user credentials

[Thomas Robinson]

The following is a bug report for triage and review. I've been unable to 
locate an adequate fix or discussion for this issue; however, I have 
found an acceptable workaround.



When built on OSX, SVN versions 1.6.16 (r1073529) and 1.6.17 (r1128011) 
appear to handle authentication challenges on commit in a non-robust 
manner.


The testing that follows is against a Google Code project that I 
currently maintain code for, which may be found here:

http://code.google.com/p/rf-ace/


Here is a sparse log of a fresh checkout and commit using SVN version 
1.6.16 (r1073529) on OSX. All builds are inclusive of ra-neon:


$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace.svn 
--username trobin...@systemsbiology.org

... file data ...
Checked out revision 265.

$ cd rf-ace.svn
... make some changes to existing files ...

$ svn commit
... write the log in my default editor ...

"svn-commit.tmp" 35L, 1392C written
svn: Commit failed (details follow):
svn: access to '/svn/!svn/act/c23cbe26-fda3-46d6-a358-d1d20738c4bf' 
forbidden

svn: Your commit message was left in a temporary file:
svn: 
'/path/to/my/repo/scrubbed/from/this/report/rf-ace.svn/svn-commit.tmp'


This same behavior exhibits in 1.6.17 (r1128011), and when a log message 
is given using -m.




Here is an approximately equivalent session using SVN version 1.6.11 
(r934486) in CentOS 6:


$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace 
--username trobin...@systemsbiology.org

... file data ...
Checked out revision 265.

$ cd rf-ace
... make some changes to existing files ...

$ svn up
... file data ...
Checked out revision 269.

$ svn commit -m "Irrelevant log message you can find in r270 of rf-ace"
Authentication realm:  Google Code 
Subversion Repository

Password for 'trobinso':
[In which I press enter here to fall back to explicit Username 
specification]


Authentication realm:  Google Code 
Subversion Repository

Username: trobin...@systemsbiology.org
Password for 'trobin...@systemsbiology.org': [My correct password is 
entered here]

Sendingtest/argparse_test.hpp
Transmitting file data .
---
ATTENTION!  Your password for authentication realm:

    Google Code Subversion Repository

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/my/home/directory/.subversion/servers'.
---
Store password unencrypted (yes/no)? yes [I know, I know. See my notes 
below.]


Committed revision 270.


Note that on personal dev boxes, authentication information has been 
stored locally in ~/.subversion (which, I note as an aside, is something 
I only do with definedly-insecure passwords like those automatically 
generated by Google Code on machines that are for internal development 
only). This, too, may cause the issue.


My workaround, of course, is obvious. For all versions of SVN, 
specifying the username explicitly (a la "--username 
trobin...@systemsbiology.org") immediately follows up with a challenge 
for my password. I have not verified if this resolves future commit 
attempts.



The catalyst for the issue is Google's recent transition of Google Code 
login system to that of Google Accounts. In this case, for conflicting 
users, the issue only exposed itself when we cut back over to our 
original usernames, and I would speculate this occurs if (and only if)

the same username is specified with an alternate password (as mine was).

Thus, we have a compelling case for potentially spurious handling of 
conflicting user credentials, as may well expose themselves in the 
migration of Google Code SVN repositories. In which I would speculate 
that the right approach would be to invalidate the cached copy of the 
user's credentials and re-challenge both the username and the password. 
Ideally, this behavior would be grafted into a configuration value, 
should it not already exist.



As you might expect, searching for this information is nigh-impossible 
for this exact edge condition, and you will probably receive several 
queries of a similar nature as Google continues to transition accounts 
with access to Google Code. Thus my posting of this bug report: assuming 
my hypothesis is correct, it's a case of inconsistent credential 
handling that results in a non-intuitive error message. As above, this 
would be better handled by configurable invalidation of the user's 
cached credentials.


Thus concludes my report. Please copy me on any mail you expect for me 
to see, as I am not a subscriber to this list.



Best regards,
- Tom

Re: update in 1.6.17 slower?

[Seth Daniel]

On Sat, Aug 20, 2011 at 12:10:46AM +0400, Ivan Zhakov wrote:
> On Fri, Aug 19, 2011 at 03:27, Seth Daniel
>  wrote:
> > Hello,
> >
> > Recently I upgraded from 1.6.9 to 1.6.17.  'svn up' is very noticeably
> > slower than it used to be.  I didn't see anything in the CHANGES file
> > about signficant 'update' changes so I was wondering if this was expected?
> >
> > With 1.6.9 I didn't turn off authz (even though I don't use it) but I
> > thought maybe it was the problem with 1.6.17.  No luck.  (btw, I'm using
> > Apache + https.  I turned *off* authz using SVNPathAuthz off).  checkout
> > and other operations are very snappy.
> >
> > I am using default options when building subversion so I'm using neon.
> > It's neon 0.25 (comes with Centos 5.4).
> >
> It could be related to the following change in Subversion 1.6.15:
> [[
>* filter unreadable paths for 'svn ls' and 'svn co' (r997026, -070, -474)
> ]]
> 
> Log message for revision r997026  is:
> [[[
> For issue #3709 ("Inconsistency between "svn list" and "svn
> checkout"), teach the mod_dav_svn tree walker logic to authorize
> access to the paths it touches.
> 
> * subversion/mod_dav_svn/repos.c
>  (do_walk): Replace a decade-old TODO about checking authorization on
>a directory's children with, you know, code that checks
>authorization on a directory's children.
> ]]]


Seems likely.  Thank you for the response.

-- 
seth /\ sethdaniel.org

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

[Dennis Jones]

"Dennis Jones"  wrote in message 
news:j2m6a0$763$1...@dough.gmane.org...
>
> "Stephen Butler"  wrote in message 
> news:e19fc591-322d-4775-8d5f-9bea8b791...@elego.de...
>
>>On Aug 19, 2011, at 18:45 , Les Mikesell wrote:
>>
>>> On 8/19/2011 11:20 AM, Dennis Jones wrote:
>>>

> I would suggest to compare what actually is in that revision in the
> old and new repository. Do they match, or anything differs?

 There is no new repository.  I am trying to create a new, clean 
 repository
 from the old server (of which I only have remote access).
>>>
>>> Your new, clean repository should have the contents up to the commit 
>>> that failed.
>
> Okay, then I will take a look and report back.

Revision 3186 was committed successfully.  It was a delete of a folder.  The 
next revision, 3187 is the one that failed, it is just a normal bunch of 
modified files.

I cannot re-run the svnadmin load, because at this point, the repository has 
already been created, and svnadmin load expects an empty repository.  I wish 
I could start the load from a specific revision, but I don't see a way to do 
that.  Is there?

- Dennis