Re: Dealing with binaries and migrating a 36G repository

2013-04-13 Thread Johan Corveleyn 
[ Please don't top-post on this list, i.e. put your reply at the
bottom or inline, thanks. More below. ]

On Sat, Apr 13, 2013 at 6:08 AM, James Marcus  wrote:
> On Fri, Apr 12, 2013 at 9:27 PM, Ryan Schmidt
>  wrote:
>>
>>
>> On Apr 12, 2013, at 11:35, James Marcus  wrote:
>>
>> > I actually started a migration with svnsync so that I didn't have to
>> > worry about network issues related to transferring a single 36GB file on an
>> > unreliable network. But I ran into this issue: Cannot accept non-LF line
>> > endings in 'svn:log' property  [500, #125005]
>> >
>>
>> You should fix the svn:log property of that revision so that it does not
>> contain non-LF line endings.
>>
> I did fix it, but there are many, how do you deal with hundreds maybe
> thousands?

I believe svnadmin dump/load (with 1.7) fixes those automatically. So
one option is to use that (or to use those to create an intermediate
repository which you can then transfer with svnsync). Or repair the
svn:log properties in the source repository with some script.

HTH
--
Johan

Re: Dealing with binaries and migrating a 36G repository

2013-04-13 Thread Johan Corveleyn 
On Sat, Apr 13, 2013 at 9:38 AM, Johan Corveleyn  wrote:
> [ Please don't top-post on this list, i.e. put your reply at the
> bottom or inline, thanks. More below. ]
>
> On Sat, Apr 13, 2013 at 6:08 AM, James Marcus  wrote:
>> On Fri, Apr 12, 2013 at 9:27 PM, Ryan Schmidt
>>  wrote:
>>>
>>>
>>> On Apr 12, 2013, at 11:35, James Marcus  wrote:
>>>
>>> > I actually started a migration with svnsync so that I didn't have to
>>> > worry about network issues related to transferring a single 36GB file on 
>>> > an
>>> > unreliable network. But I ran into this issue: Cannot accept non-LF line
>>> > endings in 'svn:log' property  [500, #125005]
>>> >
>>>
>>> You should fix the svn:log property of that revision so that it does not
>>> contain non-LF line endings.
>>>
>> I did fix it, but there are many, how do you deal with hundreds maybe
>> thousands?
>
> I believe svnadmin dump/load (with 1.7) fixes those automatically. So
> one option is to use that (or to use those to create an intermediate
> repository which you can then transfer with svnsync). Or repair the
> svn:log properties in the source repository with some script.
>
> HTH
> --
> Johan

Ah, and perhaps svnrdump also works. Not sure, you'll have to test it
(or perhaps someone else on this list knows ...).

--
Johan

Re: Error loading revision via svnrdump

2013-04-13 Thread Stefan Sperling 
On Fri, Apr 12, 2013 at 06:35:44PM -0500, Richard Gavel wrote:
> FYI, it got past the revision it had trouble with when I used "svnadmin load" 
> vs "svnrdump load"
> 
> From: Richard Gavel
> Sent: Friday, April 12, 2013 5:44 PM
> To: 'users@subversion.apache.org'
> Subject: Error loading revision via svnrdump
> 
> This process worked without issue when using a version of Visual SVN based 
> upon a 1.7.8 version of the Subversion base

This is a known issue in svnrdump and serf which will be fixed
with the Subversion 1.8 release.

See http://svn.haxx.se/dev/archive-2013-04/0184.shtml

Re: Dealing with binaries and migrating a 36G repository

2013-04-13 Thread Daniel Shahaf 
Johan Corveleyn wrote on Sat, Apr 13, 2013 at 09:41:46 +0200:
> On Sat, Apr 13, 2013 at 9:38 AM, Johan Corveleyn  wrote:
> > [ Please don't top-post on this list, i.e. put your reply at the
> > bottom or inline, thanks. More below. ]
> >
> > On Sat, Apr 13, 2013 at 6:08 AM, James Marcus  
> > wrote:
> >> On Fri, Apr 12, 2013 at 9:27 PM, Ryan Schmidt
> >>  wrote:
> >>>
> >>>
> >>> On Apr 12, 2013, at 11:35, James Marcus  wrote:
> >>>
> >>> > I actually started a migration with svnsync so that I didn't have to
> >>> > worry about network issues related to transferring a single 36GB file 
> >>> > on an
> >>> > unreliable network. But I ran into this issue: Cannot accept non-LF line
> >>> > endings in 'svn:log' property  [500, #125005]
> >>> >
> >>>
> >>> You should fix the svn:log property of that revision so that it does not
> >>> contain non-LF line endings.
> >>>
> >> I did fix it, but there are many, how do you deal with hundreds maybe
> >> thousands?
> >
> > I believe svnadmin dump/load (with 1.7) fixes those automatically. So
> > one option is to use that (or to use those to create an intermediate
> > repository which you can then transfer with svnsync). Or repair the
> > svn:log properties in the source repository with some script.
> >
> > HTH
> > --
> > Johan
> 
> Ah, and perhaps svnrdump also works. Not sure, you'll have to test it
> (or perhaps someone else on this list knows ...).

The LF check happens in the repos layer, but 'svnadmin load' uses the FS
API directly so it doesn't trip that check.  svnsync can't do this so
I think it has a (half-supported?) flag to auto-fix non-LF svn:*
properties.

As an aside, has anyone mentioned the authz + svnsync approach to
filtering history (as opposed to svnrdump | svndumpfilter) in this
thread yet?

Subversion strangeness under MacOSX

2013-04-13 Thread Robert Heller 
Is there something special about Subversion under MacOSX WRT SSL
Certificates? Is it necessary to install additional package(s)? Some
people I am working with are having a problem with subversion and https:

tests-MacBook-Pro-2:BioKey-0.7.2.10 ed$ svn checkout
https://www.assembla.com/svn/BKE/trunk
Error validating server certificate for 'https://www.assembla.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *.assembla.com
 - Valid: from Mon, 11 Mar 2013 18:34:10 GMT until Tue, 11 Mar 2014
18:34:10 GMT
 - Issuer: Cybertrust Inc
 - Fingerprint:
5f:61:b9:33:3f:36:02:74:16:41:c3:b3:10:36:6c:39:f9:0c:e7:40
(R)eject, accept (t)emporarily or accept (p)ermanently? t



-- 
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

Difference between pre-commit and start-commit

2013-04-13 Thread Richard Cavell 
Hi, folks,

I apologize in advance for not being able to figure this out. What exactly is 
the difference between the pre-commit hook and the start-commit hook?

Also, am I right in thinking that all I have to do to "install" such a hook is 
to write a script, or modify the existing template, and then rename it as the 
same name without the ".tmpl"? (Or on Windows, add ".bat" or ".exe")

Richard

Re: Dealing with binaries and migrating a 36G repository

2013-04-13 Thread Les Mikesell 
On Fri, Apr 12, 2013 at 11:08 PM, James Marcus  wrote:
> I did fix it, but there are many, how do you deal with hundreds maybe
> thousands?

I did some sort of script, but I think it took the revision on the
command line and only did one at a time, so I had to paste in the
number from the sync error.   This has probably been a very common
problem, though, since early versions of subversion permitted those
entries.  Maybe someone has a better script.

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

Re: Subversion Ruby Binding: Server certificate verification failed: issuer is not trusted

2013-04-13 Thread Joe Swatosh 
On Fri, Apr 12, 2013 at 6:27 AM, Daniel Shahaf  wrote:
> Christian Plewnia wrote on Fri, Apr 12, 2013 at 15:22:52 +0200:
>> For a start I will let Ruby execute the SVN commands on the shell, which
>> is not nice but so far works for me. However, if I find some time I
>> would like to look into extending the mapping. Am I right, that SWIG is
>> used to generate the bindings and everything related to the binding can
>> be found in
>> http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/?
>>
>> If I find the time and get some results I will of course let you know.
>
> If you have any questions about implementing the change, feel free to
> ask on #svn-dev (on Freenode) or on the dev@ list.  The list is probably
> better in this case since we don't have many swig/rb experts.
>
> Daniel


I don't have nearly the time I'd like (or used to have) to work on the
bindings, so if you have improvements please submit patches (bug
fixes, docs, improved test coverage, updating existing methods to use
non-deprecated APIs, all welcome) to the dev list.

--
Joe

Re: Difference between pre-commit and start-commit

2013-04-13 Thread Ryan Schmidt 

On Apr 13, 2013, at 09:43, Richard Cavell wrote:

> I apologize in advance for not being able to figure this out.  What exactly 
> is the difference between the pre-commit hook and the start-commit hook?

The start-commit hook is executed before the client has transmitted the 
revision content to the server. The pre-commit hook is executed after the 
client has transmitted the revision content to the server but before it has 
been accepted by the server. The post-commit hook is executed after the 
revision has been accepted by the server.

So, if you just want to reject a commit based on user credentials, use 
start-commit. If you want to reject a commit based on the contents of the 
incoming revision, use pre-commit. And if you want to notify people of a 
successful commit, use post-commit.


> Also, am I right in thinking that all I have to do to "install" such a hook 
> is to write a script, or modify the existing template, and then rename it as 
> the same name without the ".tmpl"?

And make sure it has the execute bit.


> (Or on Windows, add ".bat" or ".exe")

Re: Subversion strangeness under MacOSX

2013-04-13 Thread Andy Levy 
On Sat, Apr 13, 2013 at 10:20 AM, Robert Heller  wrote:

> Is there something special about Subversion under MacOSX WRT SSL
> Certificates? Is it necessary to install additional package(s)? Some
> people I am working with are having a problem with subversion and https:
>
> tests-MacBook-Pro-2:BioKey-0.7.2.10 ed$ svn checkout
> https://www.assembla.com/svn/BKE/trunk
> Error validating server certificate for 'https://www.assembla.com:443':
>  - The certificate is not issued by a trusted authority. Use the
>fingerprint to validate the certificate manually!
> Certificate information:
>  - Hostname: *.assembla.com
>  - Valid: from Mon, 11 Mar 2013 18:34:10 GMT until Tue, 11 Mar 2014
> 18:34:10 GMT
>  - Issuer: Cybertrust Inc
>  - Fingerprint:
> 5f:61:b9:33:3f:36:02:74:16:41:c3:b3:10:36:6c:39:f9:0c:e7:40
> (R)eject, accept (t)emporarily or accept (p)ermanently?


I'm getting a 501 Not Implemented error.

Calvin:tmp andy$ svn co https://www.assembla.com/svn/BKE/trunk BKE
svn: Server sent unexpected return value (501 Not Implemented) in response
to OPTIONS request for 'https://www.assembla.com/svn/BKE/trunk'

Attempting that URL via a browser gets me a 404.

OS X 10.6.8, SVN version 1.6.17 (r1128011) (don't have a more recent
release available at the moment).

Re: Subversion strangeness under MacOSX

2013-04-13 Thread Branko Čibej 
On 13.04.2013 19:48, Andy Levy wrote:
>
>
>
> On Sat, Apr 13, 2013 at 10:20 AM, Robert Heller  > wrote:
>
> Is there something special about Subversion under MacOSX WRT SSL
> Certificates? Is it necessary to install additional package(s)? Some
> people I am working with are having a problem with subversion and
> https:
>
> tests-MacBook-Pro-2:BioKey-0.7.2.10 ed$ svn checkout
> https://www.assembla.com/svn/BKE/trunk
> Error validating server certificate for
> 'https://www.assembla.com:443':
>  - The certificate is not issued by a trusted authority. Use the
>fingerprint to validate the certificate manually!
> Certificate information:
>  - Hostname: *.assembla.com 
>  - Valid: from Mon, 11 Mar 2013 18:34:10 GMT until Tue, 11 Mar 2014
> 18:34:10 GMT
>  - Issuer: Cybertrust Inc
>  - Fingerprint:
> 5f:61:b9:33:3f:36:02:74:16:41:c3:b3:10:36:6c:39:f9:0c:e7:40
> (R)eject, accept (t)emporarily or accept (p)ermanently?
>


I'm not sure what you think is wrong with this prompt. But, ...


> I'm getting a 501 Not Implemented error.
>
> Calvin:tmp andy$ svn co https://www.assembla.com/svn/BKE/trunk BKE
> svn: Server sent unexpected return value (501 Not Implemented) in
> response to OPTIONS request for 'https://www.assembla.com/svn/BKE/trunk' 
>
> Attempting that URL via a browser gets me a 404.
>
> OS X 10.6.8, SVN version 1.6.17 (r1128011) (don't have a more recent
> release available at the moment).

... this is something you should take up with Assembla.

-- Brane


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: Dealing with binaries and migrating a 36G repository

2013-04-13 Thread Johan Corveleyn 
On Sat, Apr 13, 2013 at 3:23 PM, Daniel Shahaf  wrote:
> Johan Corveleyn wrote on Sat, Apr 13, 2013 at 09:41:46 +0200:
>> On Sat, Apr 13, 2013 at 9:38 AM, Johan Corveleyn  wrote:
>> > [ Please don't top-post on this list, i.e. put your reply at the
>> > bottom or inline, thanks. More below. ]
>> >
>> > On Sat, Apr 13, 2013 at 6:08 AM, James Marcus  
>> > wrote:
>> >> On Fri, Apr 12, 2013 at 9:27 PM, Ryan Schmidt
>> >>  wrote:
>> >>>
>> >>>
>> >>> On Apr 12, 2013, at 11:35, James Marcus  wrote:
>> >>>
>> >>> > I actually started a migration with svnsync so that I didn't have to
>> >>> > worry about network issues related to transferring a single 36GB file 
>> >>> > on an
>> >>> > unreliable network. But I ran into this issue: Cannot accept non-LF 
>> >>> > line
>> >>> > endings in 'svn:log' property  [500, #125005]
>> >>> >
>> >>>
>> >>> You should fix the svn:log property of that revision so that it does not
>> >>> contain non-LF line endings.
>> >>>
>> >> I did fix it, but there are many, how do you deal with hundreds maybe
>> >> thousands?
>> >
>> > I believe svnadmin dump/load (with 1.7) fixes those automatically. So
>> > one option is to use that (or to use those to create an intermediate
>> > repository which you can then transfer with svnsync). Or repair the
>> > svn:log properties in the source repository with some script.
>> >
>> > HTH
>> > --
>> > Johan
>>
>> Ah, and perhaps svnrdump also works. Not sure, you'll have to test it
>> (or perhaps someone else on this list knows ...).
>
> The LF check happens in the repos layer, but 'svnadmin load' uses the FS
> API directly so it doesn't trip that check.  svnsync can't do this so
> I think it has a (half-supported?) flag to auto-fix non-LF svn:*
> properties.

Ah, I thought I remembered that I got them auto-repaired when I did an
svnadmin dump + load (with 1.7.x), but I'm not sure anymore (it was
with a test migration a year ago).

> As an aside, has anyone mentioned the authz + svnsync approach to
> filtering history (as opposed to svnrdump | svndumpfilter) in this
> thread yet?

Ah yes, good suggestion (if the OP finds a way to repair his log
entries, or a way to let svnsync accept them).

James, you may want to search the list archives a bit for this:
basically, if you set up path-based authz for the "svnsync user", and
deny the svnsync user access to the paths you want to filter out,
that's also a way to create a copy of your repository minus the paths
you don't want.

But remember what Thorsten said: you're creating a new repository,
with a "new history", so it must have another UUID than the original,
and existing working copies need to be discarded ... everyone needs to
get a new checkout.

--
Johan

Re: Subversion strangeness under MacOSX

2013-04-13 Thread William Retert 
It should be https://subversion.assembla.com/svn/BKE/trunk



On Sat, Apr 13, 2013 at 12:48 PM, Andy Levy  wrote:

>
>
>
> On Sat, Apr 13, 2013 at 10:20 AM, Robert Heller wrote:
>
>> Is there something special about Subversion under MacOSX WRT SSL
>> Certificates? Is it necessary to install additional package(s)? Some
>> people I am working with are having a problem with subversion and https:
>>
>> tests-MacBook-Pro-2:BioKey-0.7.2.10 ed$ svn checkout
>> https://www.assembla.com/svn/BKE/trunk
>> Error validating server certificate for 'https://www.assembla.com:443':
>>  - The certificate is not issued by a trusted authority. Use the
>>fingerprint to validate the certificate manually!
>> Certificate information:
>>  - Hostname: *.assembla.com
>>  - Valid: from Mon, 11 Mar 2013 18:34:10 GMT until Tue, 11 Mar 2014
>> 18:34:10 GMT
>>  - Issuer: Cybertrust Inc
>>  - Fingerprint:
>> 5f:61:b9:33:3f:36:02:74:16:41:c3:b3:10:36:6c:39:f9:0c:e7:40
>> (R)eject, accept (t)emporarily or accept (p)ermanently?
>
>
> I'm getting a 501 Not Implemented error.
>
> Calvin:tmp andy$ svn co https://www.assembla.com/svn/BKE/trunk BKE
> svn: Server sent unexpected return value (501 Not Implemented) in response
> to OPTIONS request for 'https://www.assembla.com/svn/BKE/trunk'
>
> Attempting that URL via a browser gets me a 404.
>
> OS X 10.6.8, SVN version 1.6.17 (r1128011) (don't have a more recent
> release available at the moment).
>

Re: Include relative externals in svn log/svn update?

2013-04-13 Thread Johan Corveleyn 
On Fri, Mar 8, 2013 at 4:35 PM, Stefan Zumwiese  wrote:
> Am 11.02.2013 22:08, schrieb Stefan Zumwiese:
>
>> I'm planning on setting up a repository which looks like this:
>>
>>\common
>>\common\folder1
>>\common\folder2
>>\project1
>>
>> project1 would include folder1 and folder2 via relative svn:externals
>> properties. Other projects in the same repository could include the same
>> and/or other common folders.
>
>
> Maybe I should give some more background about what we want to achieve: our
> goal is to have the code of multiple projects/products and all common parts
> in one repository, without the need to specify explicit revisions for the
> common parts which are pulled into single projects via svn:externals. For
> each project/product a branch would be created once it is put into
> maintenance mode. This means that also the common parts are branched. Each
> project is therefore free to make changes to common parts, but does not see
> changes made to common parts by other products (unless explicitly merged).
>
> \trunk\common
> \trunk\common\folder1
> \trunk\common\folder2
> \trunk\project1
> \trunk\project2
> \branches\project1_v1 <-- complete branch of \trunk
> \branches\project2_v3 <-- complete branch of \trunk
>
> To keep the size of a checkout at a reasonable size, only the relevant
> common parts should be pulled in via externals. One would than check out
> e.g. \trunk\project1.

Sorry for the late reply, but better late than never I suppose ...

We have a similar setup, where multiple interrelated projects and
sub-projects are next to each other, below trunk. We also create
complete branches of the entire trunk, for every release of a project.
But we only introduce externals for those release branches (the
externals are not defined on trunk -- that's because developers
usually have some mix of projects they're working on, and then they
don't want 'common1' checked out twice, below project1 and project2).

To be a bit more concrete, our layout looks as follows (suppose
project1 depends on common1 and common2, and project2 only depends on
common1):

/trunk/common1
/trunk/common2
/trunk/project1
/trunk/project2
/branches/project1/v1 <-- complete branch of /trunk
/branches/project1/v2 <-- complete branch of /trunk
/branches/project1/v3 <-- complete branch of /trunk
/branches/project1/try <-- dummy dir with externals definition
/branches/project1/prod <-- dummy dir with externals definition
/branches/project2/v1 <-- complete branch of /trunk
/branches/project2/v2 <-- complete branch of /trunk
/branches/project2/try <-- dummy dir with externals definition
/branches/project2/prod <-- dummy dir with externals definition

So:
- At any time we have two "active branches", called "try" (release
which is undergoing QA) and "prod" (current production version -- this
branch only gets urgent fixes merged from trunk, which need to be put
into production as urgent patches).
- The directory "try" contains nothing but an svn:externals property,
which refers to the concrete subdirs of the release branch that's
currently considered the try-branch (we use repository-relative
externals for that).

For example, the svn:externals of /branches/project1/try might look like this:

^/branches/project1/v3/project1 project1
^/branches/project1/v3/common1 common1
^/branches/project1/v3/common2 common2

And the svn:externals of project2/prod might look like this:

^/branches/project2/v1/project2 project2
^/branches/project2/v1/common1 common1


Our build server can just keep a checkout of ^/branches/project1/try
or ^/branches/project2/prod, or ..., and this checkout only contains
what's needed. It will also switch automatically to the new release
upon 'svn update', when the externals are changed to a new version.

The externals definitions in those "try" and "prod" dirs are updated
automatically by a script during our release process.

> When experimenting with this planned repository layout and testing some use
> cases, I ran into these issues:
>
>
>> When viewing the log of project1, I can see only the direct changes of
>> project1, not the changes that were made in the relative externals.
>>
>> Since I'm currently deciding on the repository structure: how good are
>> chances that something like --include-externals or
>> --include-local-externals might be added as an option to svn log in the
>> future?
>
> (Choose a name for the flag as you see fit.)

Okay, might be interesting, but I'm not sure if this is easily doable
given the current design of externals. Externals are a pure
client-side concept ... the server just sees this as another property
but doesn't do anything special with it. Maybe some other dev can
comment more on this ... (if you hear nothing, feel free to file a
feature request in the issue tracker --- regardless of how realistic
this is with the current design, I feel this is still a legitimate
user request).

During our release process, we solve this problem with a little script
(actually, w

Re: Dealing with binaries and migrating a 36G repository

2013-04-13 Thread kmradke 
> >> >>> > I actually started a migration with svnsync so that I didn't 
have to
> >> >>> > worry about network issues related to transferring a single
> 36GB file on an
> >> >>> > unreliable network. But I ran into this issue: Cannot 
> accept non-LF line
> >> >>> > endings in 'svn:log' property  [500, #125005]
> >> >>> >
> >> >>>
> >> >>> You should fix the svn:log property of that revision so that 
> it does not
> >> >>> contain non-LF line endings.
> >> >>>
> >> >> I did fix it, but there are many, how do you deal with hundreds 
maybe
> >> >> thousands?
> >> >
> >> > I believe svnadmin dump/load (with 1.7) fixes those automatically. 
So
> >> > one option is to use that (or to use those to create an 
intermediate
> >> > repository which you can then transfer with svnsync). Or repair the
> >> > svn:log properties in the source repository with some script.
> >> >
> >> > HTH
> >> > --
> >> > Johan
> >>
> >> Ah, and perhaps svnrdump also works. Not sure, you'll have to test it
> >> (or perhaps someone else on this list knows ...).
> >
> > The LF check happens in the repos layer, but 'svnadmin load' uses the 
FS
> > API directly so it doesn't trip that check.  svnsync can't do this so
> > I think it has a (half-supported?) flag to auto-fix non-LF svn:*
> > properties.
> 
> Ah, I thought I remembered that I got them auto-repaired when I did an
> svnadmin dump + load (with 1.7.x), but I'm not sure anymore (it was
> with a test migration a year ago).

I had to use this recently to ignore the non-LF problems when loading
with 1.7:

svnadmin load --bypass-prop-validation 

http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.html#svn.ref.svnadmin.sw.bypass_prop_validation

Kevin R.

Re: Dealing with binaries and migrating a 36G repository

2013-04-13 Thread Daniel Shahaf 
Johan Corveleyn wrote on Sun, Apr 14, 2013 at 00:45:34 +0200:
> On Sat, Apr 13, 2013 at 3:23 PM, Daniel Shahaf  
> wrote:
> > As an aside, has anyone mentioned the authz + svnsync approach to
> > filtering history (as opposed to svnrdump | svndumpfilter) in this
> > thread yet?
> 
> Ah yes, good suggestion (if the OP finds a way to repair his log
> entries, or a way to let svnsync accept them).
> 

Set up authz, then do 'svnrdump dump | svnadmin load'.  This will
preserve the CRLF-y log messages.

> James, you may want to search the list archives a bit for this:

Do we have that written down somewhere?  I wonder if this is the sort of
thing we should have on a faq or wiki page or something.

Re: Include relative externals in svn log/svn update?

2013-04-13 Thread Daniel Shahaf 
Johan Corveleyn wrote on Sun, Apr 14, 2013 at 02:37:13 +0200:
> On Fri, Mar 8, 2013 at 4:35 PM, Stefan Zumwiese  wrote:
> > Am 11.02.2013 22:08, schrieb Stefan Zumwiese:
> >> When viewing the log of project1, I can see only the direct changes of
> >> project1, not the changes that were made in the relative externals.
> >>
> >> Since I'm currently deciding on the repository structure: how good are
> >> chances that something like --include-externals or
> >> --include-local-externals might be added as an option to svn log in the
> >> future?
> >
> > (Choose a name for the flag as you see fit.)
> 
> Okay, might be interesting, but I'm not sure if this is easily doable
> given the current design of externals. Externals are a pure
> client-side concept ... the server just sees this as another property
> but doesn't do anything special with it. Maybe some other dev can
> comment more on this 

You're correct, 'svn log' is about walking the history of a node (and
about showing the per-revision changed-paths info) and isn't aware of
externals.  "SVN_PROP_EXTERNALS" does not occur in the server-side code.

That said, there is syntax 2 of 'svn log':

% $svn h log | head
log: Show the log messages for a set of revision(s) and/or path(s).
usage: 1. log [PATH][@REV]
   2. log URL[@REV] [PATH...]

It wants a URL, but the PATH arguments can contain slashes, so a little
script can construct a correct invocation that covers cwd + externals.

(You probably want to call one of our APIs ---
svn_wc_parse_externals_description3()? --- (maybe via the bindings)
rather than re-invent svn:externals parsing.)

Daniel

Re: Subversion strangeness under MacOSX

2013-04-13 Thread Branko Čibej 
On 13.04.2013 20:01, William Retert wrote:
> It should be https://subversion.assembla.com/svn/BKE/trunk
>

You /really/ should take it up with Assembla. You can hardly expect
anyone on this list to help with your problem if you (a) don't take the
trouble to describe it in detail, and (b) give examples that require
authentication, so no-one can even try to reproduce what you're seeing.

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com