RE: svnsync: Authorization failed

[Li, Hubert]

Thanks, Eric. I tried to add –username and –password in svnsync, and got the 
same error messages. Yes, 1.6.6 is old, but we have to use it for some reasons.

Thanks,
Hubert Li
ARRIS

From: Eric Johnson [mailto:e...@tibco.com]
Sent: Monday, September 14, 2015 2:43 PM
To: Li, Hubert 
Cc: users@subversion.apache.org
Subject: Re: svnsync: Authorization failed

Two quick thoughts (I'm not a developer, just a user of Subversion):

1) 1.6.6 is old. If you can upgrade, you might get easier to understand error 
messages.

2) The sync operation is trying to sync from some other place. Given that your 
credentials to access the zch124... repository may be fine, the likely culprit 
is the credentials to access the source of the sync request data. In any case, 
"svnsync help sync" will give you the command line options you can pass to set 
the creds.

Eric.


On Sun, Sep 13, 2015 at 8:02 PM, Li, Hubert 
mailto:hubert...@arris.com>> wrote:
Hi,

I got the following error when I ran svnsync:
[root@zch124svn01 conf]# svnsync sync 
svn://zch124svn01.ap.mot-mobility.com/miracle3
…
subversion/svnserve/serve.c:167: (apr_err=170001)
svnsync: Authorization failed

but I can co or export it with the same user, e.g.
[/dept/stb/...67/svn/test]$ svn export 
svn://zch124svn01.ap.mot-mobility.com/miracle3
Amiracle3
…

Below is my system info:
[root@zch124svn01 conf]# cat /etc/issue
CentOS release 6.4 (Final)
Kernel \r on an \m

[root@zch124svn01 conf]# svnsync --version
svnsync, version 1.6.6 (r40053)
   compiled Oct 24 2013, 13:59:58
…

BTW, we can sync it before rebooting the system, but after reboot it, we got 
this error. I start the service with this command:
svnserve -d -r /svn_files/svn/

Thanks,
Hubert Li
ARRIS

RE: svnsync: Authorization failed

[Li, Hubert]

I got the new error messages below:

[root@zch124svn01 tmp]# svnsync info 
svn://zch124svn01.ap.mot-mobility.com/miracle3
subversion/libsvn_subr/sqlite.c:192: (apr_err=200030)
svnsync: database is locked
subversion/libsvn_subr/sqlite.c:362: (apr_err=200030)
svnsync: database is locked

Thanks,
Hubert Li
ARRIS


From: Li, Hubert
Sent: Monday, September 14, 2015 3:00 PM
To: 'Eric Johnson' 
Cc: users@subversion.apache.org
Subject: RE: svnsync: Authorization failed

Thanks, Eric. I tried to add –username and –password in svnsync, and got the 
same error messages. Yes, 1.6.6 is old, but we have to use it for some reasons.

Thanks,
Hubert Li
ARRIS

From: Eric Johnson [mailto:e...@tibco.com]
Sent: Monday, September 14, 2015 2:43 PM
To: Li, Hubert mailto:hubert...@arris.com>>
Cc: users@subversion.apache.org
Subject: Re: svnsync: Authorization failed

Two quick thoughts (I'm not a developer, just a user of Subversion):

1) 1.6.6 is old. If you can upgrade, you might get easier to understand error 
messages.

2) The sync operation is trying to sync from some other place. Given that your 
credentials to access the zch124... repository may be fine, the likely culprit 
is the credentials to access the source of the sync request data. In any case, 
"svnsync help sync" will give you the command line options you can pass to set 
the creds.

Eric.


On Sun, Sep 13, 2015 at 8:02 PM, Li, Hubert 
mailto:hubert...@arris.com>> wrote:
Hi,

I got the following error when I ran svnsync:
[root@zch124svn01 conf]# svnsync sync 
svn://zch124svn01.ap.mot-mobility.com/miracle3
…
subversion/svnserve/serve.c:167: (apr_err=170001)
svnsync: Authorization failed

but I can co or export it with the same user, e.g.
[/dept/stb/...67/svn/test]$ svn export 
svn://zch124svn01.ap.mot-mobility.com/miracle3
Amiracle3
…

Below is my system info:
[root@zch124svn01 conf]# cat /etc/issue
CentOS release 6.4 (Final)
Kernel \r on an \m

[root@zch124svn01 conf]# svnsync --version
svnsync, version 1.6.6 (r40053)
   compiled Oct 24 2013, 13:59:58
…

BTW, we can sync it before rebooting the system, but after reboot it, we got 
this error. I start the service with this command:
svnserve -d -r /svn_files/svn/

Thanks,
Hubert Li
ARRIS

Re: 1.9 - Can't resolve to 'mine full' option for binary file conflict

[Stefan Hett]

On 9/14/2015 7:56 AM, Daniel Becroft wrote:

Hi guys,


I've just upgraded to SVN 1.9. One of the first things I noticed is 
that when a binary file conflict is raised during an SVN update, I can 
no longer use the 'mine-full' option to resolve.


The only options I have are: (r) working and (tf) theirs-full.

I can't use the 'r' (working) option, as I get a message of "Invalid 
option; use diff/edit/merge/launch before choosing 'mark resolved'.


If I postpone, and try resolving afterwards, I get the following errors;
> svn resolve file.binary --accept mine-full
svn: warning: W155027: Conflict on 'file.binary' could not be resolved 
because the chosen version of the file is not available.

svn: E155027: Failure occurred resolving one or more conflicts

I can't find anything in the release notes about the removal of the 
'mine-full' option on binary files. Was it intentional? If so, what's 
the intended workflow for resolution?


Current version:
svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0)
   compiled Aug 26 2015, 17:09:55 on x86/x86_64-microsoft-windows6.2.9200

Cheers,
Daniel B.

Hi Daniel,

just to second ur observation:
I think I ran into the same problem last Thursday/Friday using TSVN 
1.9.1. I didn't report it yet because I didn't check out whether it's a 
TSVN or an SVN issue.
Using TSVN, it however also gives me the "file not found" error when I 
try to resolve a binary conflict selecting "Use Repository version" 
during the merge dialog.


I'm sure u are already ware, but just in case: My workaround was to let 
the file in conflict and afterwards resolve the conflict by reverting 
the file (so it was in the repository's state which I intended).


--
Regards,
Stefan Hett

Re: svnsync: Authorization failed

[Stefan Hett]

Normally running a clean-up would solve these lock issues (svn cleanup).

Sorry, no idea with ur actual authorization issue. If things worked 
before, I'd assume it's something with outdated/invalid credentials or 
problems due to some server-side upgrades of the authorization 
methods/set-up.


I got the new error messages below:

[root@zch124svn01 tmp]# svnsync info 
svn://zch124svn01.ap.mot-mobility.com/miracle3


subversion/libsvn_subr/sqlite.c:192: (apr_err=200030)

svnsync: database is locked

subversion/libsvn_subr/sqlite.c:362: (apr_err=200030)

svnsync: database is locked

Thanks,

Hubert Li

ARRIS

*From:*Li, Hubert
*Sent:* Monday, September 14, 2015 3:00 PM
*To:* 'Eric Johnson' 
*Cc:* users@subversion.apache.org
*Subject:* RE: svnsync: Authorization failed

Thanks, Eric. I tried to add –username and –password in svnsync, and 
got the same error messages. Yes, 1.6.6 is old, but we have to use it 
for some reasons.


Thanks,

Hubert Li

ARRIS

*From:*Eric Johnson [mailto:e...@tibco.com]
*Sent:* Monday, September 14, 2015 2:43 PM
*To:* Li, Hubert mailto:hubert...@arris.com>>
*Cc:* users@subversion.apache.org 
*Subject:* Re: svnsync: Authorization failed

Two quick thoughts (I'm not a developer, just a user of Subversion):

1) 1.6.6 is old. If you can upgrade, you might get easier to 
understand error messages.


2) The sync operation is trying to sync /from/ some other place. Given 
that your credentials to access the zch124... repository may be fine, 
the likely culprit is the credentials to access the source of the sync 
request data. In any case, "svnsync help sync" will give you the 
command line options you can pass to set the creds.


Eric.

On Sun, Sep 13, 2015 at 8:02 PM, Li, Hubert > wrote:


Hi,

I got the following error when I ran svnsync:

[root@zch124svn01 conf]# svnsync sync
svn://zch124svn01.ap.mot-mobility.com/miracle3


…

subversion/svnserve/serve.c:167: (apr_err=170001)

svnsync: Authorization failed

but I can co or export it with the same user, e.g.

[/dept/stb/...67/svn/test]$ svn export
svn://zch124svn01.ap.mot-mobility.com/miracle3


Amiracle3

…

Below is my system info:

[root@zch124svn01 conf]# cat /etc/issue

CentOS release 6.4 (Final)

Kernel \r on an \m

[root@zch124svn01 conf]# svnsync --version

svnsync, version 1.6.6 (r40053)

   compiled Oct 24 2013, 13:59:58

…

BTW, we can sync it before rebooting the system, but after reboot
it, we got this error. I start the service with this command:

svnserve -d -r /svn_files/svn/

Thanks,

Hubert Li

ARRIS




--
Regards,
Stefan Hett

AW: AW: AW: AW: NTLM authentication in subversion 1.9.0?

[Grabner Markus]

I'm pretty sure that ApacheHaus used the sources from here:
https://github.com/YvesR/mod_authn_ntlm

At least the options in my config file are consistent with the source code. The 
code is based on (and almost identical to) this project:
http://sourceforge.net/projects/mod-auth-sspi

The mod-auth-sspi module has been in use at our site for several years, but 
only supports apache-2.2.

I'm also aware of some related projects, but as far as I understand these have 
not been maintained for some time:
http://sourceforge.net/projects/modntlm
https://git.samba.org/?p=jerry/mod_auth_ntlm_winbind.git

Kind regards,
Markus


-Ursprüngliche Nachricht-
Von: Philip Martin [mailto:philip.mar...@wandisco.com] 
Gesendet: Samstag, 12. September 2015 11:00
An: Grabner Markus
Cc: 'Branko Cibej'; users@subversion.apache.org
Betreff: Re: AW: AW: AW: NTLM authentication in subversion 1.9.0?

Grabner Markus  writes:

> I'm using the following binaries from 
> https://www.apachehaus.com/cgi-bin/download.plx (all compiled with Visual 
> Studio 2012 for 32-bit Windows):
> *) Apache 2.4.16
> *) Mod Auth NTLM for Apache 2.4.x

What exactly is "Mod Auth NTLM"?  The apachehaus site does not have
obvious source code links.  There appear to be several NTLM modules on
the net and I cannot identify the one you are using.  Can you provide
the source code, or a link to the source code?

-- 
Philip Martin
WANdisco

RE: 1.9 - Can't resolve to 'mine full' option for binary file conflict

[Bert Huijben]

> -Original Message-
> From: Stefan Hett [mailto:ste...@egosoft.com]
> Sent: maandag 14 september 2015 09:54
> To: users@subversion.apache.org
> Subject: Re: 1.9 - Can't resolve to 'mine full' option for binary file 
> conflict
> 
> On 9/14/2015 7:56 AM, Daniel Becroft wrote:
> > Hi guys,
> >
> >
> > I've just upgraded to SVN 1.9. One of the first things I noticed is
> > that when a binary file conflict is raised during an SVN update, I can
> > no longer use the 'mine-full' option to resolve.
> >
> > The only options I have are: (r) working and (tf) theirs-full.
> >
> > I can't use the 'r' (working) option, as I get a message of "Invalid
> > option; use diff/edit/merge/launch before choosing 'mark resolved'.
> >
> > If I postpone, and try resolving afterwards, I get the following errors;
> > > svn resolve file.binary --accept mine-full
> > svn: warning: W155027: Conflict on 'file.binary' could not be resolved
> > because the chosen version of the file is not available.
> > svn: E155027: Failure occurred resolving one or more conflicts
> >
> > I can't find anything in the release notes about the removal of the
> > 'mine-full' option on binary files. Was it intentional? If so, what's
> > the intended workflow for resolution?
> >
> > Current version:
> > svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0)
> >compiled Aug 26 2015, 17:09:55 on x86/x86_64-microsoft-windows6.2.9200
> >
> > Cheers,
> > Daniel B.
> Hi Daniel,
> 
> just to second ur observation:
> I think I ran into the same problem last Thursday/Friday using TSVN
> 1.9.1. I didn't report it yet because I didn't check out whether it's a
> TSVN or an SVN issue.
> Using TSVN, it however also gives me the "file not found" error when I
> try to resolve a binary conflict selecting "Use Repository version"
> during the merge dialog.
> 
> I'm sure u are already ware, but just in case: My workaround was to let
> the file in conflict and afterwards resolve the conflict by reverting
> the file (so it was in the repository's state which I intended).

In case of a binary file the original working copy version is left as the 
working version, whereas for text conflict the working copy version is changed 
into a mine version and a best effort merge is performed to the a new working 
copy version potentially containing conflict markers.

In this case you probably get the result you want by just choosing the working 
copy version. The Subversion developer responsible for choosing this UI 
determined that it didn't make much sense to offer two different resolve 
options with exactly the same result.

Bert

> 
> --
> Regards,
> Stefan Hett

Re: 1.9 - Can't resolve to 'mine full' option for binary file conflict

[Daniel Becroft]

Thanks, Bert. I understand the removal of "mine-full", and combining it
with the "working" option. But, the issue is that there is no functional
option that allows the user to select to keep the "working" (mine) version
of the conflict.
If I select (r) (accept the working version of the file), I get a
validation error: "Invalid option; use diff/edit/merge/launch before
choosing 'mark resolved".
The remaining three options (theirs-full, postpone and postpone all) either
result in the conflict remaining, or data loss by removing the working file
altogether.

On Mon, Sep 14, 2015 at 8:04 PM Bert Huijben  wrote:

>
>
> > -Original Message-
> > From: Stefan Hett [mailto:ste...@egosoft.com]
> > Sent: maandag 14 september 2015 09:54
> > To: users@subversion.apache.org
> > Subject: Re: 1.9 - Can't resolve to 'mine full' option for binary file
> conflict
> >
> > On 9/14/2015 7:56 AM, Daniel Becroft wrote:
> > > Hi guys,
> > >
> > >
> > > I've just upgraded to SVN 1.9. One of the first things I noticed is
> > > that when a binary file conflict is raised during an SVN update, I can
> > > no longer use the 'mine-full' option to resolve.
> > >
> > > The only options I have are: (r) working and (tf) theirs-full.
> > >
> > > I can't use the 'r' (working) option, as I get a message of "Invalid
> > > option; use diff/edit/merge/launch before choosing 'mark resolved'.
> > >
> > > If I postpone, and try resolving afterwards, I get the following
> errors;
> > > > svn resolve file.binary --accept mine-full
> > > svn: warning: W155027: Conflict on 'file.binary' could not be resolved
> > > because the chosen version of the file is not available.
> > > svn: E155027: Failure occurred resolving one or more conflicts
> > >
> > > I can't find anything in the release notes about the removal of the
> > > 'mine-full' option on binary files. Was it intentional? If so, what's
> > > the intended workflow for resolution?
> > >
> > > Current version:
> > > svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0)
> > >compiled Aug 26 2015, 17:09:55 on
> x86/x86_64-microsoft-windows6.2.9200
> > >
> > > Cheers,
> > > Daniel B.
> > Hi Daniel,
> >
> > just to second ur observation:
> > I think I ran into the same problem last Thursday/Friday using TSVN
> > 1.9.1. I didn't report it yet because I didn't check out whether it's a
> > TSVN or an SVN issue.
> > Using TSVN, it however also gives me the "file not found" error when I
> > try to resolve a binary conflict selecting "Use Repository version"
> > during the merge dialog.
> >
> > I'm sure u are already ware, but just in case: My workaround was to let
> > the file in conflict and afterwards resolve the conflict by reverting
> > the file (so it was in the repository's state which I intended).
>
> In case of a binary file the original working copy version is left as the
> working version, whereas for text conflict the working copy version is
> changed into a mine version and a best effort merge is performed to the a
> new working copy version potentially containing conflict markers.
>
> In this case you probably get the result you want by just choosing the
> working copy version. The Subversion developer responsible for choosing
> this UI determined that it didn't make much sense to offer two different
> resolve options with exactly the same result.
>
> Bert
>
> >
> > --
> > Regards,
> > Stefan Hett
>
>
>

Re: 1.9 - Can't resolve to 'mine full' option for binary file conflict

[Philip Martin]

Indeed there is a bug:

svnadmin create repo
svnmucc -mm -U file://`pwd`/repo put repo/format f propset svn:mime-type 
application/octet f
svnmucc -mm -U file://`pwd`/repo put repo/db/format f
svn co file://`pwd`/repo@1 wc
echo xx > wc/f
svn up wc

The initial conflict prompt offers:

  Conflict discovered in binary file 'wc/f'.
  Select: (p) postpone, (tf) their version, (s) show all options: 

Trying (s) offers:

(r)  - accept the working copy version of file  [working]
(tf) - accept the incoming version of file  [theirs-full]
(p)  - mark the conflict to be resolved later  [postpone]
(q)  - postpone all remaining conflicts
(s)  - show this list (also 'h', '?')
  Words in square brackets are the corresponding --accept option arguments.

  Select: (p) postpone, (tf) their version, (s) show all options: 

Trying (r) gives:

  Invalid option; use diff/edit/merge/launch before choosing 'mark resolved'.

but one cannot use those options for a binary file.

Perhaps we need something like this:

Index: ../src/subversion/svn/conflict-callbacks.c
===
--- ../src/subversion/svn/conflict-callbacks.c  (revision 1702397)
+++ ../src/subversion/svn/conflict-callbacks.c  (working copy)
@@ -1013,7 +1013,7 @@
  the file if they've edited it, or at least looked at
  the diff. */
   if (opt->choice == svn_wc_conflict_choose_merged
-  && ! knows_something)
+  && ! knows_something && ! is_binary)
 {
   SVN_ERR(svn_cmdline_fprintf(
 stderr, iterpool,

or perhaps this:

Index: ../src/subversion/svn/conflict-callbacks.c
===
--- ../src/subversion/svn/conflict-callbacks.c  (revision 1702397)
+++ ../src/subversion/svn/conflict-callbacks.c  (working copy)
@@ -1013,7 +1013,7 @@
  the file if they've edited it, or at least looked at
  the diff. */
   if (opt->choice == svn_wc_conflict_choose_merged
-  && ! knows_something)
+  && ! knows_something && diff_allowed)
 {
   SVN_ERR(svn_cmdline_fprintf(
 stderr, iterpool,




Daniel Becroft  writes:

> Thanks, Bert. I understand the removal of "mine-full", and combining it
> with the "working" option. But, the issue is that there is no functional
> option that allows the user to select to keep the "working" (mine) version
> of the conflict.
> If I select (r) (accept the working version of the file), I get a
> validation error: "Invalid option; use diff/edit/merge/launch before
> choosing 'mark resolved".
> The remaining three options (theirs-full, postpone and postpone all) either
> result in the conflict remaining, or data loss by removing the working file
> altogether.
>
> On Mon, Sep 14, 2015 at 8:04 PM Bert Huijben  wrote:
>
>>
>>
>> > -Original Message-
>> > From: Stefan Hett [mailto:ste...@egosoft.com]
>> > Sent: maandag 14 september 2015 09:54
>> > To: users@subversion.apache.org
>> > Subject: Re: 1.9 - Can't resolve to 'mine full' option for binary file
>> conflict
>> >
>> > On 9/14/2015 7:56 AM, Daniel Becroft wrote:
>> > > Hi guys,
>> > >
>> > >
>> > > I've just upgraded to SVN 1.9. One of the first things I noticed is
>> > > that when a binary file conflict is raised during an SVN update, I can
>> > > no longer use the 'mine-full' option to resolve.
>> > >
>> > > The only options I have are: (r) working and (tf) theirs-full.
>> > >
>> > > I can't use the 'r' (working) option, as I get a message of "Invalid
>> > > option; use diff/edit/merge/launch before choosing 'mark resolved'.
>> > >
>> > > If I postpone, and try resolving afterwards, I get the following
>> errors;
>> > > > svn resolve file.binary --accept mine-full
>> > > svn: warning: W155027: Conflict on 'file.binary' could not be resolved
>> > > because the chosen version of the file is not available.
>> > > svn: E155027: Failure occurred resolving one or more conflicts
>> > >
>> > > I can't find anything in the release notes about the removal of the
>> > > 'mine-full' option on binary files. Was it intentional? If so, what's
>> > > the intended workflow for resolution?
>> > >
>> > > Current version:
>> > > svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0)
>> > >compiled Aug 26 2015, 17:09:55 on
>> x86/x86_64-microsoft-windows6.2.9200
>> > >
>> > > Cheers,
>> > > Daniel B.
>> > Hi Daniel,
>> >
>> > just to second ur observation:
>> > I think I ran into the same problem last Thursday/Friday using TSVN
>> > 1.9.1. I didn't report it yet because I didn't check out whether it's a
>> > TSVN or an SVN issue.
>> > Using TSVN, it however also gives me the "file not found" error when I
>> > try to resolve a binary conflict selecting "Use Repository version"
>> > during the merge dialog.
>> >
>> > I'm sure u are already ware, but just in case: My workaround was to let
>> > the fil

Re: 1.9 - Can't resolve to 'mine full' option for binary file conflict

[Philip Martin]

Philip Martin  writes:

> or perhaps this:
>
> Index: ../src/subversion/svn/conflict-callbacks.c
> ===
> --- ../src/subversion/svn/conflict-callbacks.c(revision 1702397)
> +++ ../src/subversion/svn/conflict-callbacks.c(working copy)
> @@ -1013,7 +1013,7 @@
>   the file if they've edited it, or at least looked at
>   the diff. */
>if (opt->choice == svn_wc_conflict_choose_merged
> -  && ! knows_something)
> +  && ! knows_something && diff_allowed)
>  {
>SVN_ERR(svn_cmdline_fprintf(
>  stderr, iterpool,
>
>

That allows 'r' to work, but if 'r' is going to be allowed it should
probably be shown by the first prompt, so perhaps:

Index: ../src/subversion/svn/conflict-callbacks.c
===
--- ../src/subversion/svn/conflict-callbacks.c  (revision 1702397)
+++ ../src/subversion/svn/conflict-callbacks.c  (working copy)
@@ -796,7 +796,7 @@
 }
   else
 {
-  if (knows_something)
+  if (knows_something || is_binary)
 *next_option++ = "r";
 
   /* The 'mine-full' option selects the ".mine" file so only offer
@@ -1013,7 +1013,7 @@
  the file if they've edited it, or at least looked at
  the diff. */
   if (opt->choice == svn_wc_conflict_choose_merged
-  && ! knows_something)
+  && ! knows_something && diff_allowed)
 {
   SVN_ERR(svn_cmdline_fprintf(
 stderr, iterpool,


-- 
Philip Martin
WANdisco

Re: 1.9 - Can't resolve to 'mine full' option for binary file conflict

[Stefan Sperling]

On Mon, Sep 14, 2015 at 12:27:44PM +0100, Philip Martin wrote:
> Index: ../src/subversion/svn/conflict-callbacks.c
> ===
> --- ../src/subversion/svn/conflict-callbacks.c(revision 1702397)
> +++ ../src/subversion/svn/conflict-callbacks.c(working copy)
> @@ -796,7 +796,7 @@
>  }
>else
>  {
> -  if (knows_something)
> +  if (knows_something || is_binary)
>  *next_option++ = "r";
>  
>/* The 'mine-full' option selects the ".mine" file so only offer
> @@ -1013,7 +1013,7 @@
>   the file if they've edited it, or at least looked at
>   the diff. */
>if (opt->choice == svn_wc_conflict_choose_merged
> -  && ! knows_something)
> +  && ! knows_something && diff_allowed)
>  {
>SVN_ERR(svn_cmdline_fprintf(
>  stderr, iterpool,
> 
> 

I agree.

And thanks for mopping up after me ;-)
I believe I accidentally broke this in r1667692.

Re: svnsync: Authorization failed

[Eric Johnson]

Hi Hubert,

There should be two sets of credentials you can pass to svnsync. I don't
remember what they're called for 1.6. Did you try passing the
--sync-username and --sync-password?

Eric.

On Sun, Sep 13, 2015 at 11:59 PM, Li, Hubert  wrote:

> Thanks, Eric. I tried to add –username and –password in svnsync, and got
> the same error messages. Yes, 1.6.6 is old, but we have to use it for some
> reasons.
>
>
>
> Thanks,
>
> Hubert Li
>
> ARRIS
>
>
>
> *From:* Eric Johnson [mailto:e...@tibco.com]
> *Sent:* Monday, September 14, 2015 2:43 PM
> *To:* Li, Hubert 
> *Cc:* users@subversion.apache.org
> *Subject:* Re: svnsync: Authorization failed
>
>
>
> Two quick thoughts (I'm not a developer, just a user of Subversion):
>
>
>
> 1) 1.6.6 is old. If you can upgrade, you might get easier to understand
> error messages.
>
>
>
> 2) The sync operation is trying to sync *from* some other place. Given
> that your credentials to access the zch124... repository may be fine, the
> likely culprit is the credentials to access the source of the sync request
> data. In any case, "svnsync help sync" will give you the command line
> options you can pass to set the creds.
>
>
>
> Eric.
>
>
>
>
>
> On Sun, Sep 13, 2015 at 8:02 PM, Li, Hubert  wrote:
>
> Hi,
>
>
>
> I got the following error when I ran svnsync:
>
> [root@zch124svn01 conf]# svnsync sync svn://
> zch124svn01.ap.mot-mobility.com/miracle3
>
> …
>
> subversion/svnserve/serve.c:167: (apr_err=170001)
>
> svnsync: Authorization failed
>
>
>
> but I can co or export it with the same user, e.g.
>
> [/dept/stb/...67/svn/test]$ svn export svn://
> zch124svn01.ap.mot-mobility.com/miracle3
>
> Amiracle3
>
> …
>
>
>
> Below is my system info:
>
> [root@zch124svn01 conf]# cat /etc/issue
>
> CentOS release 6.4 (Final)
>
> Kernel \r on an \m
>
>
>
> [root@zch124svn01 conf]# svnsync --version
>
> svnsync, version 1.6.6 (r40053)
>
>compiled Oct 24 2013, 13:59:58
>
> …
>
>
>
> BTW, we can sync it before rebooting the system, but after reboot it, we
> got this error. I start the service with this command:
>
> svnserve -d -r /svn_files/svn/
>
>
>
> Thanks,
>
> Hubert Li
>
> ARRIS
>
>
>
>
>

Re: 1.9 - Can't resolve to 'mine full' option for binary file conflict

[Pete Harlan]

On Mon, Sep 14, 2015 at 3:03 AM, Bert Huijben  wrote:
>> On 9/14/2015 7:56 AM, Daniel Becroft wrote:
>> > Hi guys,
>> >
>> >
>> > I've just upgraded to SVN 1.9. One of the first things I noticed is
>> > that when a binary file conflict is raised during an SVN update, I can
>> > no longer use the 'mine-full' option to resolve.
>> >
>> > The only options I have are: (r) working and (tf) theirs-full.
...
> The Subversion developer responsible for choosing this UI determined that it
> didn't make much sense to offer two different resolve options with exactly the
> same result.

Perhaps a user or script wants to resolve a merge of some files in
favor of their versions, regardless of whether the file is binary.

You're now requiring that user or script to consider binary-ness in
order to use the UI, no?

--Pete

start-commit hook client capabilities - mergeinfo only?

[Brett Randall]

I have these versions:

Client: svn, version 1.8.8 (r1568071) with ra_svn, ra_local and ra_serf
Server: version 1.8.9 (r1591380) with fs_fs
Using protocol https://

I created and installed a start-commit hook that echos its third
parameter (client capabilities) to a log file, ran a test-commit with
the above software, and all that is echoed for client-capabilities is:
mergeinfo.  The repository access is over https:// .

Any idea what is going-on here?  There are other capabilities
mentioned in the documentation, such as "depth", "log-revprops", but
these don't appear.  In particular I am interested in the new
auto-props feature in 1.8+ clients - is there a capability sent for
that, and if not, should there be?

Thanks
Brett

RE: svnsync: Authorization failed

[Li, Hubert]

Yes, I tried --sync-username and --sync-password:
subversion/svnserve/serve.c:167: (apr_err=170001)
svnsync: Authorization failed

Thanks,
Hubert Li
ARRIS

o: +86 571-2811-7111
c: +86 130-1890-4390

From: Eric Johnson [mailto:e...@tibco.com]
Sent: Tuesday, September 15, 2015 12:16 AM
To: Li, Hubert 
Cc: users@subversion.apache.org
Subject: Re: svnsync: Authorization failed

Hi Hubert,

There should be two sets of credentials you can pass to svnsync. I don't 
remember what they're called for 1.6. Did you try passing the --sync-username 
and --sync-password?

Eric.

On Sun, Sep 13, 2015 at 11:59 PM, Li, Hubert 
mailto:hubert...@arris.com>> wrote:
Thanks, Eric. I tried to add –username and –password in svnsync, and got the 
same error messages. Yes, 1.6.6 is old, but we have to use it for some reasons.

Thanks,
Hubert Li
ARRIS

From: Eric Johnson [mailto:e...@tibco.com]
Sent: Monday, September 14, 2015 2:43 PM
To: Li, Hubert mailto:hubert...@arris.com>>
Cc: users@subversion.apache.org
Subject: Re: svnsync: Authorization failed

Two quick thoughts (I'm not a developer, just a user of Subversion):

1) 1.6.6 is old. If you can upgrade, you might get easier to understand error 
messages.

2) The sync operation is trying to sync from some other place. Given that your 
credentials to access the zch124... repository may be fine, the likely culprit 
is the credentials to access the source of the sync request data. In any case, 
"svnsync help sync" will give you the command line options you can pass to set 
the creds.

Eric.


On Sun, Sep 13, 2015 at 8:02 PM, Li, Hubert 
mailto:hubert...@arris.com>> wrote:
Hi,

I got the following error when I ran svnsync:
[root@zch124svn01 conf]# svnsync sync 
svn://zch124svn01.ap.mot-mobility.com/miracle3
…
subversion/svnserve/serve.c:167: (apr_err=170001)
svnsync: Authorization failed

but I can co or export it with the same user, e.g.
[/dept/stb/...67/svn/test]$ svn export 
svn://zch124svn01.ap.mot-mobility.com/miracle3
Amiracle3
…

Below is my system info:
[root@zch124svn01 conf]# cat /etc/issue
CentOS release 6.4 (Final)
Kernel \r on an \m

[root@zch124svn01 conf]# svnsync --version
svnsync, version 1.6.6 (r40053)
   compiled Oct 24 2013, 13:59:58
…

BTW, we can sync it before rebooting the system, but after reboot it, we got 
this error. I start the service with this command:
svnserve -d -r /svn_files/svn/

Thanks,
Hubert Li
ARRIS

Re: start-commit hook client capabilities - mergeinfo only?

[Branko Čibej]

On 15.09.2015 00:38, Brett Randall wrote:
> I have these versions:
>
> Client: svn, version 1.8.8 (r1568071) with ra_svn, ra_local and ra_serf
> Server: version 1.8.9 (r1591380) with fs_fs
> Using protocol https://
>
> I created and installed a start-commit hook that echos its third
> parameter (client capabilities) to a log file, ran a test-commit with
> the above software, and all that is echoed for client-capabilities is:
> mergeinfo.  The repository access is over https:// .

I can confirm this happens with file:// and svn://, too.

> Any idea what is going-on here?

It could be we're confusing repository capabilities vs. client
capabilities somewhere in the code. In any case, the documentation (and
the implementation) clearly states we should be seeing client
capabilities here, so it looks like a bug at first glance.

>   There are other capabilities
> mentioned in the documentation, such as "depth", "log-revprops", but
> these don't appear.  In particular I am interested in the new
> auto-props feature in 1.8+ clients - is there a capability sent for
> that, and if not, should there be?

That would be the "inherited-props" capability. How these inherited
properties are interpreted (e.g., as in the case of svn:auto-props) is a
client-side decision; the server isn't consulted. A custom-built client
might announce the inherited-props capability but not actually interpret
auto-props, for example.

-- Brane

Incomplete SVN dump files

[Eric Johnson]

I'm in a situation where I'm dumping Subversion repositories from remote
locations (using svnrdump).

The repositories are big enough, and the network connections between
destinations just unstable enough that the repositories aren't making it
all in one dump call. I've noticed, for one repository in particular, that
I actually got a dump file that had only a part of the last commit before
the connection broke.

When I loaded up the repository, Subversion reported no problems on the
svnadmin load, but it seems to me it should have noticed that the final
commit recorded in the dump file was incomplete, and discarded it. Instead,
it happily loaded it, and reported no problems.

At least I was lucky enough to check that it was complete, and I used a
technique  to drop all but the last
revision. Now I can load a new dump file from the commit that was
incomplete.

This brings me back to my question - shouldn't the load process ignore the
last commit if it is incomplete in the dump file? That way I know I have an
error to address!

Eric.