Re: reposurgeon now writes Subversion repositories

[Martin Furter]

On 11/30/12 00:55, Eric S. Raymond wrote:

Ben Reser:

The only thing that's really lacking here is a good way to pass along
extra property values in an easy to configure way per
server/repository so that you can use a client defined value to put it
in svn:author.  I don't really see adding support for something like
that as terribly difficult.  The only caveat I would make is that you
should realize the change here is a client side change and that it'll
take some time for users to upgrade clients (most distros are still
shipping SVN 1.6 over a year after 1.7 released).

Once you have something like that, you can expose it to the hook
scripts and they can change the svn:author field to whatever the local
repository prefers.  If local repositories want to store the local
authenticated user in a different property they can also do this.


Sounds like I should write that patch to make a preferred-ID string
available out of ~/.subversion/config, then.  As soon as possible.


I wanted to reply that this should go into ~/.subversion/servers. But i 
found the entry "username" in there. So just add a username entry to the 
global section.


HTH,
Martin

Re: svn commit: r1415451 [1/9] - in /subversion/branches/fsfs-format7/subversion/libsvn_fs_fs: fs.c fs_fs.c fs_fs.h low_level.c low_level.h rep-cache.c revprops.c revprops.h util.c util.h

[Peter Samuelson]

[stef...@apache.org]
> * subversion/libsvn_fs_fs/util.h
>   (RECOVERABLE_RETRY_COUNT,
[...]
>move_into_place): lib-locally declare functions previously
>private in fs_fs.c

This is a problem - on many OSes[*], all global functions and variables
that are not 'static', i.e., anything not file-scoped, are exported and
available to third parties from the shared library.  We don't want to
export something like move_into_place() or read_content(), even if we
don't declare it in a header file.  This is what the fs_fs__ prefix,
with double underscore, is for.

Peter

[*] On ELF platforms such as Linux, it is generally possible to have a
symbol private to a library but not file-scoped, but I'm pretty
sure we don't use this ability.  On other non-ELF Unix platforms,
this may not be possible at all.  On Windows, I guess symbols are
always exported explicitly to a DLL.

RE: 1.8 Progress

[Gavin Baumanis]

[...]
> > 3) libsvn_ra_serf stabilization.  I know there have been a couple
> > concerns that Philip has raised (EAGAIN and the random failures).
> 
> Philip and Ivan both seem keen on reinstating ra_neon.

[GB: ]  Hi Everyone,
I realise I am non-committer to SVN - but am a Software Developer none the less;
I think it is important - regardless of the route chosen to make a firm 
decision and stick to it.
The do we / don't we get rid of ra_neon has been a talking point on here for a 
really long time now and seemingly still has no "final" status.

I'd also like to add, that if the end-game is; we are going to "just" support 
serf, then surely the answer is to spend time correcting the issues in serf 
that people have noted, as opposed to spending time re-inserting neon?
Of course that assumes that we can get serf to where it needs to be - in time 
for a 1.8 release.

It might just be stating the obvious - but if we can’t get serf to where it 
needs to be for a 1.8 release of SVN - then surely it is prudent to re-insert 
ra_neon back into SVN and make 1.9 the goal for being serf-only?

Gavin.

Re: svn commit: r1415365 - in /subversion/trunk/subversion: svn/info-cmd.c tests/cmdline/info_tests.py

[Daniel Shahaf]

cmpil...@apache.org wrote on Thu, Nov 29, 2012 at 20:44:48 -:
> Author: cmpilato
> Date: Thu Nov 29 20:44:47 2012
> New Revision: 1415365
> 
> URL: http://svn.apache.org/viewvc?rev=1415365&view=rev
> Log:
> Show the ^/foo/bar repository relative URL of the item in 'svn info'
> output.
> 
> * subversion/svn/info-cmd.c
>   (print_info): Print a new line of information, "Relative URL:",
> carrying the so-called "caret syntax" of the repository relative URL.
>   (print_info_xml): Print ".." in the XML
> display to carry the repository relative URL.

Update subversion/svn/schema/ ?

Re: [PATCH] match svnauthz-validate exit code to --help promise

[Daniel Shahaf]

C. Michael Pilato wrote on Thu, Nov 29, 2012 at 14:58:07 -0500:
> On 10/09/2012 02:29 PM, Daniel Shahaf wrote:
> > svnauthz-validate --help promises exitcode==2 in most code paths:
> 
> r1415344.

Thanks.

Re: [PATCH] svn property name test functions

[Julian Foad]

I (Julian Foad) wrote:

> Nothing terribly exciting to see here.  I'm posting these patches just in 
> case someone wants to comment or pick them up, because I won't be able to 
> finish them today, or if Brane wants to take note because it's relevant to 
> the property name testing in his recent prop-name spell-check code.
> 
> The attached 'property-name-test-functions-1.patch' creates some public 
> functions:
> 
>  * subversion/include/svn_props.h
>   (svn_prop_is_known_svn_rev_prop, svn_prop_is_known_svn_node_prop,
>    svn_prop_is_known_svn_file_prop, svn_prop_is_known_svn_dir_prop): New
>     functions.
> 
> and uses them in a small number of places that were doing those sorts of test 
> in-line.

I decided to commit this patch (but not the one described below).  r1415456.

> As I have written in the log msg, we might want to expose the arrays as well 
> (or 
> possibly instead of) the functions.

I didn't write that in the commit log msg, only in the previously attached 
patch file.

- Julian


> The attached 'propdel-suppress-nonexistent-1.patch' demonstrates what I 
> was trying to do, which is make the following warnings go away:
> 
> $ svn pd svn:ignore -R contrib/cgi/
> Attempting to delete nonexistent property 'svn:ignore' on 
> 'contrib/cgi'
> Attempting to delete nonexistent property 'svn:ignore' on 
> 'contrib/cgi/...svn.cgi'
> Attempting to delete nonexistent property 'svn:ignore' on 
> 'contrib/cgi/...README'
> Attempting to delete nonexistent property 'svn:ignore' on 
> 'contrib/cgi/...log.cgi'
> 
> I want the warnings to appear only for the node kinds where that property 
> might 
> be expected, not for all of the nodes.
> 
> My current approach of suppressing the notifications seems rather wrong.  As 
> noted in the log message in the patch, I want tohave a look at what 
> 'propset' does, as maybe we should be avoiding trying to delete it from 
> the wrong node kind rather than trying and then suppressing the notification.
> 
> Or, perhaps the best solution is a middle way: try to delete from all nodes 
> (I 
> suppose we think we should do this "just in case it's there"), but 
> don't send this notification when it's the wrong node kind.

[PATCH] svn property name test functions

[Julian Foad]

Nothing terribly exciting to see here.  I'm posting these patches just in case 
someone wants to comment or pick them up, because I won't be able to finish 
them today, or if Brane wants to take note because it's relevant to the 
property name testing in his recent prop-name spell-check code.

The attached 'property-name-test-functions-1.patch' creates some public 
functions:


 * subversion/include/svn_props.h
  (svn_prop_is_known_svn_rev_prop, svn_prop_is_known_svn_node_prop,
   svn_prop_is_known_svn_file_prop, svn_prop_is_known_svn_dir_prop): New
    functions.

and uses them in a small number of places that were doing those sorts of test 
in-line.

As I have written in the log msg, we might want to expose the arrays as well 
(or possibly instead of) the functions.


The attached 'propdel-suppress-nonexistent-1.patch' demonstrates what I was 
trying to do, which is make the following warnings go away:

$ svn pd svn:ignore -R contrib/cgi/
Attempting to delete nonexistent property 'svn:ignore' on 'contrib/cgi'
Attempting to delete nonexistent property 'svn:ignore' on 
'contrib/cgi/...svn.cgi'
Attempting to delete nonexistent property 'svn:ignore' on 
'contrib/cgi/...README'
Attempting to delete nonexistent property 'svn:ignore' on 
'contrib/cgi/...log.cgi'

I want the warnings to appear only for the node kinds where that property might 
be expected, not for all of the nodes.

My current approach of suppressing the notifications seems rather wrong.  As 
noted in the log message in the patch, I want tohave a look at what 'propset' 
does, as maybe we should be avoiding trying to delete it from the wrong node 
kind rather than trying and then suppressing the notification.

Or, perhaps the best solution is a middle way: try to delete from all nodes (I 
suppose we think we should do this "just in case it's there"), but don't send 
this notification when it's the wrong node kind.

- Julian




--
Certified & Supported Apache Subversion Downloads: 
http://www.wandisco.com/subversion/download


property-name-test-functions-1.patch
Description: Binary data


propdel-suppress-nonexistent-1.patch
Description: Binary data

Re: 1.8 Progress

[C. Michael Pilato]

[I'm going to try to summarize the body of responses generated from this
original query -- a conversational reset, if you will -- so as to keep this
line of inquiry moving toward closure.]

On 11/01/2012 02:42 PM, Ben Reser wrote:
> Looking at our roadmap we have the following things still in progress:
> 
> 1) local moves/renames.  Based on the conversation I had on IRC this seems
> to be not done yet due to issues found in the original plan.  stsp says that
> if it can't be done before we want to otherwise release 1.8 he'd like to
> pull the move code entirely.  So the question here is do we wait for some
> unknown amount of time for this to complete?  Is this an important 1.8 
> feature?

Philip sez:  "I'd like to get this in.  The local-move/incoming-edit stuff
is not a huge task, I think we could get it working before the end of the year."

Stefan Sperling later responded (in another thread):  "Well, I'm starting to
think that we underestimated the size of the problem (again, as we did in
1.6), and should probably try to find a correct design before writing more
code for this (except maybe XFAILing tests).  Which means we should be
prepared to pull the moves feature from the 1.8.x branch once it is
branched, since move tracking doesn't provide any benefit if moves cannot be
updated properly. I don't think we can get this done before 1.9..."

I also seem to recall Stefan also saying something about not having time to
work on this stuff for the remainder of 2012, but I can't find a reference
for that at the moment, so perhaps I just misremembered.

OWNERSHIP:  Given Philip's comment, I believe it is reasonable to deem him
the owner of this body of work, or at least co-owner with a
possibly-time-constrained Stefan.  But perhaps all there is to "own" is the
post-branch removal of the feature?

> 2) Ev2.  The notes say this is believed to be in a releasable state?  Is
> there any work needed to verify this?  Do we need to remove the use of Ev2
> in any place to avoid releasing with compatibility shims in use? Are we
> comfortable that the API is complete?

Julian expressed doubt about whether the API was ready for prime-time.

C-Mike expressed concern about the extremely low bus factor.

Hyrum acknowledged both, and continued with:  "We can always shuffle headers
around or document the things as experimental, so committing ourselves to
the API as this point isn't my concern.  The only real limiting around Ev2
and 1.8 is issue #4116 which is svnrdump failures over ra_serf.  In the
issue, I propose using Ev2 to get around the problem, since the dumpfile
format is so incongruent with the editor.  Of course, we don't *have* to do
that, but as I've thought about it, any solution will require a bit o'
caching---which we've already implemented as part of the Ev2 shims.  We
*might* be able to implement the svnrdump editor as Ev2, shim the thing on
the client side (which gives us the required caching) and release that way.
 Or there might be a better solution I'm overlooking because I've got Ev2 on
the brain."

OWNERSHIP:  Hyrum's got the most experience here, but due to his time
contention, we may very well have no owner for this at all.  That's bad.

> 3) libsvn_ra_serf stabilization.  I know there have been a couple concerns
> that Philip has raised (EAGAIN and the random failures).

Philip and Ivan both seem keen on reinstating ra_neon.

Justin poopooed the idea of reinstating ra_neon simply to get 100% feature
coverage, suggesting that the way forward for the believed-to-be-small
fraction of folks depending on Neon-specific features is to just stick with
1.7.  (Not sure how serious he was.)

Mark expanded the scope of the discussion to include Serf's affect on
servers (growth of server logs, expanded number of server connections, etc.).

Lieven, in a neighboring thread
(http://svn.haxx.se/dev/archive-2012-11/0225.shtml), enumerated a number of
specific observed problems with ra_serf:

   > 1. When a very low Timeout is set in the apache server configuration,
   > the server truncates response bodies in some situations

   There appears to be a fix for the more egregious of these situations
   in serf already, but Lieven indicated he'd look into this one.

   > 2. ra_serf consumes way too much memory while doing large checkout's
   > (issue #4196).

   I believe I've finally fixed this with my commits to ra_serf on trunk
   this week.

   > 3. Ivan added a potential issue because ra_serf+serf are not handling
   > events on each open connection regularly. This can result in timeouts,

   Ivan submitted a patch for a portion of this work
   (http://svn.haxx.se/dev/archive-2012-11/0193.shtml), but either way
   it's not clear if this problem is theoretical only or has been observed.

   > 4. Ivan further observed that the spillbuf mechanism, used to keep
   > ra_serf reading from the REPORT connection while waiting for slow disc
   > i/o, has two drawbacks:
   >4a. the amount of data stored in the spillbuf can

Re: [PATCH] match svnauthz-validate exit code to --help promise

[C. Michael Pilato]

On 10/09/2012 02:29 PM, Daniel Shahaf wrote:
> svnauthz-validate --help promises exitcode==2 in most code paths:

r1415344.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

Re: reposurgeon now writes Subversion repositories

[Eric S. Raymond]

Ben Reser :
> The only thing that's really lacking here is a good way to pass along
> extra property values in an easy to configure way per
> server/repository so that you can use a client defined value to put it
> in svn:author.  I don't really see adding support for something like
> that as terribly difficult.  The only caveat I would make is that you
> should realize the change here is a client side change and that it'll
> take some time for users to upgrade clients (most distros are still
> shipping SVN 1.6 over a year after 1.7 released).
> 
> Once you have something like that, you can expose it to the hook
> scripts and they can change the svn:author field to whatever the local
> repository prefers.  If local repositories want to store the local
> authenticated user in a different property they can also do this.

Sounds like I should write that patch to make a preferred-ID string
available out of ~/.subversion/config, then.  As soon as possible.
 
> Given your goal that users shouldn't notice I'm going to assume you're
> allowing anonymous commits.

Actually that wasn't in my plan.  It's sufficient that every commit 
get an Internet-scoped ID, anonymity isn't required.  

My plan about "users don't notice" works like this.  Multiple instances
of my forge (the design's name is "Federation") each have lists of peer
instances. They flood project-index updates to each other.  When you do
a transaction about project foo with instance bar, it looks in the
index and transparently proxies for wherever the project actually is.

Another consequence of this design is that you can back up your project
state yourself by asking the forge federation to send you the same blob 
it would pass around if a peer said "Aaargh! I'm about to die!".

With a little work, the federated instances could set up a rolling-backup
scheme that would protect pretty well against unplanned server deaths.

I designed this after Berlios told the world it was going down, and
potentially taking hundreds of projects with it.  It's still up, but
I don't ever again want to have to bet everything on the eternal
stability of a single forge site.

This is a serious vulnerability in the open-source infrastructure.
I want to fix it.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: reposurgeon now writes Subversion repositories

[Ben Reser]

On Thu, Nov 29, 2012 at 5:49 AM, Eric S. Raymond  wrote:
> I say break the hell out of it.  The utility of Internet-scoped
> attributions is pretty high in a bunch of different ways (I love me
> some Ohloh statistics, there's one).  And I doubt "server
> verification" actually buys you much.  Whetever it does buy you you
> can keep by sticking the "verified" username in a property that
> auditing tools can see but users don't need to.
>
> Let me give you a major forinstance. I have been seriously thinking
> for a couple of years about writing a better software forge.  Many and
> various are the ways in which the existing ones all suck, but the
> single worst problem with them is probably that migrating project
> state between instances ranges from hard to impossible.
>
> For reasons I shouldn't neecd to explain, we really want to live in a
> world where a forge instance that's about to undergo planned shutdown
> can squirt its project states to a bunch of peers and have each one go
> seamlessly live on a new host.  If the forge federation is designed
> right, users shouldn't even have to know when this happens.
>
> So, guess why I had to cross Subversion off the list of VCSes my design
> would support?  Yes, that's right - system-local usernames in the forge
> database and VCSes are the single most severe point of adhesion.  I had
> to get rid of them entirely, just as DVCSes have.
>
> Subversion should do likewise.

But as people have already said the meaning of the svn:author field is
locally defined by the repository.  There is nothing preventing your
proposed software forge from defining that the author field is some
different type of value e.g. the users email address.

Heck the book even says that you shouldn't assume that svn:author is
even set (believe it won't be set if you allow anonymous commits):
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.html

The only thing that's really lacking here is a good way to pass along
extra property values in an easy to configure way per
server/repository so that you can use a client defined value to put it
in svn:author.  I don't really see adding support for something like
that as terribly difficult.  The only caveat I would make is that you
should realize the change here is a client side change and that it'll
take some time for users to upgrade clients (most distros are still
shipping SVN 1.6 over a year after 1.7 released).

Once you have something like that, you can expose it to the hook
scripts and they can change the svn:author field to whatever the local
repository prefers.  If local repositories want to store the local
authenticated user in a different property they can also do this.

Given your goal that users shouldn't notice I'm going to assume you're
allowing anonymous commits.  Right now there's really no definition of
how svn:author behaves with anonymous commits.  So I'd say that it
would be perfectly reasonable to define such a configurable value and
default to filling svn:author with it in the case of anonymous
commits.

Re: Serf crashes on fork

[C. Michael Pilato]

Perhaps this should be discussed on the serf dev list?  Or an issue filed in
their tracker?


On 11/19/2012 10:09 AM, Stefan Fuhrmann wrote:
> On Mon, Nov 19, 2012 at 2:44 PM, Philip Martin  > wrote:
> 
> Philip Martin  > writes:
> 
> > Stefan Fuhrmann  > writes:
> >
> >> On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin
> >> mailto:philip.mar...@wandisco.com>>wrote:
> >>
> >>> Stefan Fuhrmann  > writes:
> >>>
> >>> > As it turns out, your commit has only be the trigger but
> >>> > not the root cause.
> >>> >
> >>> > serf_trunk/allocator.c, serf_bucket_allocator_create(), line 147:
> >>> >
> >>> > /* ### this implies buckets cannot cross a fork/exec. desirable?
> >>> >  *
> >>> >  * ### hmm. it probably also means that buckets cannot be AROUND
> >>> >  * ### during a fork/exec. the new process will try to clean 
> them
> >>> >  * ### up and figure out there are unfreed blocks...
> >>> >  */
> >>> > apr_pool_cleanup_register(pool, allocator,
> >>> >   allocator_cleanup, allocator_cleanup);
> >>> >
> >>> > Since we fork() for hooks, we can't use hooks in ra_local
> >>> > while there is an open serf connection. Otherwise, we get
> >>> > into trouble with pool cleanups:
> >>>
> >>> Does it ever make sense for the child process to run that handler?  Is
> >>> that to allow a parent process to allocate a serf connection and then
> >>> fork off a child process to use the connection?
> 
> If the processes were behaving like that the child cleanup handlers
> would not be involved.
> 
> >>
> >> From the comments in APR/threadproc/unix/proc.c,
> >> it seems that apr_proc_create runs *all* pool cleanups
> >> in the child process to clean up duplicated file handles
> >> and such.
> >
> > apr_proc_create runs the child cleanup handlers.  Note that two handlers
> > are passed to _register, one for the parent one for the child.  I'm
> > asking why serf installs a child handler rather than passing
> > apr_pool_cleanup_null.
> 
> The cleanup handler is just releasing memory via apr_allocator_free. I
> see no reason for it to be installed as a child cleanup handler.
> 
> 
> Simply patching serf fixes the problem for me.
> 
> -- Stefan^2.
> 
> [[[
> Index: buckets/allocator.c
> ===
> --- buckets/allocator.c(revision 1685)
> +++ buckets/allocator.c(working copy)
> @@ -151,7 +151,7 @@
>   * ### up and figure out there are unfreed blocks...
>   */
>  apr_pool_cleanup_register(pool, allocator,
> -  allocator_cleanup, allocator_cleanup);
> +  allocator_cleanup, apr_pool_cleanup_null);
>  
>  return allocator;
>  }
> ]]]
> 
> -- 
> Certified & Supported Apache Subversion Downloads:
> /
> 
> http://www.wandisco.com/subversion/download
> 
> /


-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1414880 - /subversion/trunk/subversion/libsvn_client/merge.c

[Paul Burba]

On Wed, Nov 28, 2012 at 8:27 PM, C. Michael Pilato  wrote:
> On 11/28/2012 03:39 PM, Julian Foad wrote:
>> @@ -2425,10 +2441,8 @@ merge_dir_added(svn_wc_notify_state_t *s
>>>  }
>>>else
>>>  {
>>> -  const char *added_path = apr_pstrdup(merge_b->pool,
>>> -   local_abspath);
>>> -  apr_hash_set(merge_b->dry_run_added, added_path,
>>> -   APR_HASH_KEY_STRING, added_path);
>>> +  merge_b->dry_run_last_added_dir =
>>> +apr_pstrdup(merge_b->pool, local_abspath);
>>
>> Oops -- no longer setting the hash here.  Maybe use a macro or function to 
>> encapsulate both parts of the "registration".
>
> Hrm... the original logic didn't add it to the hash here, either.  I seem to
> have made that additional apr_hash_set() accidentally in r1414810.  You can
> examine the sum of my changes to this file like so:
>
>svn diff -r1414809:1414880 subversion/libsvn_client/merge.c
>
> Doing so reveals that, in the end, I didn't actually changed the behavior in
> this code section.  And yet ... it does make me wonder if this is just some
> latent bug waiting to be revealed.  Certainly seems suspect.
>
> Paul:  have you any opinions here?  To summarize, I'm wondering why, in
> merge_dir_added(), in the switch that begins like so:
>
>   /* Switch on the on-disk state of this path */
>   switch (kind)
>
> ... the merged addition of a brand new directory earns that directory a
> registration in both the dry_run_last_added_dir slot *and* the dry_run_added
> hash, but a merged directory addition atop an unversioned or previously
> deleted directory only winds up in dry_run_last_added_dir (and *not* the
> dry_run_added hash).  Any ideas?

Julian is correct, that's a bug in the original code.  We can see the
problem in merge_tests.py 2 if we add some unversioned directories
which obstruct incoming directory adds:

>mkdir A\C\Q A\C\Q2

>svn st
?   A\C\Q
?   A\C\Q2

>svn merge ^^/A/B/F A\C -r1:2
--- Merging r2 into 'A\C':
AA\C\Q
AA\C\Q2
AA\C\Q\bar
AA\C\Q\bar2
AA\C\foo
AA\C\foo2
--- Recording mergeinfo for merge of r2 into 'A\C':
 U   A\C

Do the same with a --dry-run and the output is skipped (as per Mike's
earlier problems http://svn.haxx.se/dev/archive-2012-11/0681.shtml):

>svn revert -Rq . & mkdir A\C\Q A\C\Q2

>svn merge ^^/A/B/F A\C -r1:2 --dry-run
--- Merging r2 into 'A\C':
AA\C\Q
AA\C\Q2
Skipped 'A\C\Q\bar'
Skipped 'A\C\Q\bar2'
AA\C\foo
AA\C\foo2
Summary of conflicts:
  Skipped paths: 2

Fixed and added test in r1415214.

>>>  }
>>>if (state)
>>>  *state = svn_wc_notify_state_changed;
>>> @@ -2467,6 +2481,9 @@ merge_dir_added(svn_wc_notify_state_t *s
>>>  }
>>>break;
>>>  case svn_node_file:
>>> +  if (merge_b->dry_run)
>>> +merge_b->dry_run_last_added_dir = NULL;
>>
>> Clearing that path is just an optimization, right?  (Also below.)
>
> As far as I can tell, yes.  As above, I was merely restoring the behavior to
> what it was before I started mucking with this code at all.

Hmmm, that code goes *way* back.  I 'm not sure it's even needed
anymore or if it ever was.

> --
> C. Michael Pilato 
> CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

-- 
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba

Re: svn commit: r1414880 - /subversion/trunk/subversion/libsvn_client/merge.c

[C. Michael Pilato]

On 11/28/2012 08:27 PM, C. Michael Pilato wrote:
> Paul:  have you any opinions here?  To summarize, I'm wondering why, in
> merge_dir_added(), in the switch that begins like so:
> 
>   /* Switch on the on-disk state of this path */
>   switch (kind)
> 
> ... the merged addition of a brand new directory earns that directory a
> registration in both the dry_run_last_added_dir slot *and* the dry_run_added
> hash, but a merged directory addition atop an unversioned or previously
> deleted directory only winds up in dry_run_last_added_dir (and *not* the
> dry_run_added hash).  Any ideas?

Looks like Paul agreed that there was a potential problem here, given r1415214.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

Re: Regression tests FAILs with older format repositories

[Julian Foad]

Philip Martin wrote:

> Julian Foad writes:
>>  Philip Martin wrote:
>>>  $ ./fs-test --server-minor-version=4 34
>>>  lt-fs-test: ../src/subversion/libsvn_subr/dirent_uri.c:1456: 
>>>  svn_relpath_skip_ancestor: Assertion 
>>> `relpath_is_canonical(parent_relpath)' failed.
>> 
>>  OK, I'll investigate that.
> 
> gdb shows:
> 
> #4  in prev_location(...)
>     at ../src/subversion/libsvn_fs_fs/tree.c:3246
> 3246      remainder_path = svn_relpath_skip_ancestor(copy_path, path);
> (gdb) p copy_path
> $3 = 0x77e1068e "/A/D"
> (gdb) p path
> $4 = 0x73f38728 "/A/D"
> 
> We are passing fspaths to a relpath function.  The test passes in 1.7
> because svn_relpath_skip_ancestor doesn't assert that the paths are
> relpaths and works if passed fspaths.

I see you have fixed this in r1415133.  Thanks.

- Julian

Re: reposurgeon now writes Subversion repositories

[Eric S. Raymond]

Daniel Shahaf :
> I don't see the kludge here --- git has a "author" != "committer"
> distinction, svn doesn't, so if you want to grow that distinction the
> most natural way is a new property.  Storing additional information in
> svn:author is a separate issue.

See my advocacy to Branko of going to Internet-scoped IDs. The kludge
would be maintaining the local and Internet-scoped identifications 
as different properties and having to decide which one to key on
ad-hoc.  Nothing to do with the author/committer distinction. 
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: reposurgeon now writes Subversion repositories

[Eric S. Raymond]

Branko Čibej :
> Well, I find that we don't actually spell out anywhere that svn:author
> can be pretty much any UTF-8 string. It can even contain newlines,
> although that's not recommended.

No kidding.  That's an edge case *I* surely wouldn't want to screw with.
 
> Hint: svn commit --with-revprop svn:author="Twizzle Strongpants
> "

Interreting.
 
> I'm open to suggestions, up to and including breaking that assumption,
> though obviously I'd prefer not to.

I say break the hell out of it.  The utility of Internet-scoped
attributions is pretty high in a bunch of different ways (I love me
some Ohloh statistics, there's one).  And I doubt "server
verification" actually buys you much.  Whetever it does buy you you
can keep by sticking the "verified" username in a property that
auditing tools can see but users don't need to.

Let me give you a major forinstance. I have been seriously thinking
for a couple of years about writing a better software forge.  Many and
various are the ways in which the existing ones all suck, but the
single worst problem with them is probably that migrating project
state between instances ranges from hard to impossible.

For reasons I shouldn't neecd to explain, we really want to live in a
world where a forge instance that's about to undergo planned shutdown
can squirt its project states to a bunch of peers and have each one go
seamlessly live on a new host.  If the forge federation is designed
right, users shouldn't even have to know when this happens.

So, guess why I had to cross Subversion off the list of VCSes my design
would support?  Yes, that's right - system-local usernames in the forge
database and VCSes are the single most severe point of adhesion.  I had
to get rid of them entirely, just as DVCSes have.

Subversion should do likewise.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: reposurgeon now writes Subversion repositories

[Daniel Shahaf]

Philip Martin wrote on Thu, Nov 29, 2012 at 13:27:09 +:
> Daniel Shahaf  writes:
> 
> > Specifically, the server code special-cases svn:author and svn:date ---
> > an administrator would have to use a pre-commit hook (or patch the
> > server) to avoid those being set from the authentication info and system
> > clock.
> 
>   - for RA access (a network client like svn) the server sets both
> svn:author and svn:date, the client has no control.
> 
>   - for FS access (a filesystem client like svnadmin) the server sets
> svn:date and the client controls svn:author.
> 
> svnadmin load is not as efficient as it could be as it has to do a
> revprop change after each commit to set svn:date.

And replay() users (svnrdump/svnsync) need to set both date and author.

AW: reposurgeon now writes Subversion repositories

[Markus Schaber]

Hi,

Von: Eric S. Raymond [mailto:e...@thyrsus.com]
> > How does reposurgeon handle empty directories with (node) properties?
> 
> Currently by ignoring all of them except svn:ignore, which it turns
> into .gitignore content on the gitspace side.  And now vice-versa, too.
> 
> Not clear what else it *could* do.  I'd take suggestions.

AFAIR, SvnBridge (which bridges SVN to Team Foundation Server for CodePlex) 
creates a hidden .svnproperties file where all the properties of the directory 
and files are stored.

I'm not really sure, but maybe this could be used as some standard to bridge 
svn properties to non-svn VCSes.

Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com
CODESYS internet forum: http://forum.codesys.com

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

Re: reposurgeon now writes Subversion repositories

[Daniel Shahaf]

(note, other half of the thread is on dev@svn only..)

Eric S. Raymond wrote on Thu, Nov 29, 2012 at 06:46:37 -0500:
> Daniel Shahaf :
> > You might also seek community consensus to reserve an svn:foo name for
> > the "original author" property --- perhaps svn:original-author --- so
> > that reposurgeon and other git->svn tools can interoperate in the way
> > they transfer the "original author" information.
> 
> OK.  But I like the idea of letting the users set their own author
> content string better.  Instead of another layer of kluges, why

I don't see the kludge here --- git has a "author" != "committer"
distinction, svn doesn't, so if you want to grow that distinction the
most natural way is a new property.  Storing additional information in
svn:author is a separate issue.

> > >   Subversion has a concept of "flows"; that is, named segments of
> > >   history corresponding to files or directories that are created when
> > >   the path is added, cloned when the path is copied, and deleted when
> > >   the path is deleted. This information is not preserved in import
> > >   streams or the internal representation that reposurgeon uses.  Thus,
> > >   after editing, the flow boundaries of a Subversion history may be
> > >   arbitrarily changed.
> > > 
> > > This is me being obsessive about documenting the details.  I think it
> > > is doubtful that most Subversion users even know flows exist.
> > 
> > I think you're saying that adds might turn into copies, and vice-versa.
> > That is something users would notice --- it is certainly exposed in the
> > UI --- even though node-id's are not exposed to clients.
> 
> I'm saying nobody thinks of flows when they do branch copies.  It's
> not just that users don't see node IDs, it's that no part of most users'
> mental model of how Subversion works resembles them.

I'm still not sure what you have in mind.  I note that 'svn log' and
'svn blame' cross both file copies and branch creation --- that's one
effect of "'svn cp foo bar; svn ci' causes bar to be related to foo".

> -- 
>   http://www.catb.org/~esr/";>Eric S. Raymond

Re: svn commit: r1414728 - in /subversion/trunk: ./ build/generator/ subversion/bindings/cxxhl/ subversion/bindings/cxxhl/include/ subversion/bindings/cxxhl/include/types/ subversion/bindings/cxxhl/sr

[Branko Čibej]

On 29.11.2012 14:22, Hyrum K Wright wrote:
> On Wed, Nov 28, 2012 at 3:10 PM, Branko Čibej  wrote:
>
>> On 28.11.2012 17:15, Philip Martin wrote:
>>> Branko Čibej  writes:
>>>
 On 28.11.2012 15:39, br...@apache.org wrote:
> Author: brane
> Date: Wed Nov 28 14:39:42 2012
> New Revision: 1414728
>
> URL: http://svn.apache.org/viewvc?rev=1414728&view=rev
> Log:
> Getting sidetracked for a bit: create placeholder and update build for
> a future high-level C++ API for Subversion, based on the same
>> principles
> as JavaHL.
 Lest anyone become too worried about this: I'm not going to let this
 project divert my attention from getting 1.8 out the door. I had this
 idea on the back burner for a long time, and just now found a bit of
 time when I had to clear my head; so I decided to at least get the build
 infrastructure in place.
>>> How does this compare to Hyrum's "object model"?
>>>
>>>   notes/object-model.txt
>>>   ^/subversion/branches/object-model
>> I don't know yet. I'll be looking at that more closely when the time
>> comes, but I'll also take notes from JavaHL. I feel it's important that
>> we hide the details of the C API (for example, its dependency on APR)
>> from this high-level interface.
>
> The object model stuff is probably a bit dated, but some of the ideas
> probably still hold.  If there's anything I learned through that
> experience, it was that we'll probably need to use something like pimpl for
> any type of backward compatibility within the C++ bindings themselves.  Ugh.

Would versioned namespaces not do the trick?

e.g.:

namespace svncxxhl_v1 { ... }
namespace svncxxhl_v2 { using svncxxhl_v1::foo; ... }
namespace svn { namespace cxxhl = svncxxhl_v2; }



-- Brane

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

Re: reposurgeon now writes Subversion repositories

[Philip Martin]

Daniel Shahaf  writes:

> Specifically, the server code special-cases svn:author and svn:date ---
> an administrator would have to use a pre-commit hook (or patch the
> server) to avoid those being set from the authentication info and system
> clock.

  - for RA access (a network client like svn) the server sets both
svn:author and svn:date, the client has no control.

  - for FS access (a filesystem client like svnadmin) the server sets
svn:date and the client controls svn:author.

svnadmin load is not as efficient as it could be as it has to do a
revprop change after each commit to set svn:date.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: svn commit: r1414728 - in /subversion/trunk: ./ build/generator/ subversion/bindings/cxxhl/ subversion/bindings/cxxhl/include/ subversion/bindings/cxxhl/include/types/ subversion/bindings/cxxhl/sr

[Hyrum K Wright]

On Wed, Nov 28, 2012 at 3:10 PM, Branko Čibej  wrote:

> On 28.11.2012 17:15, Philip Martin wrote:
> > Branko Čibej  writes:
> >
> >> On 28.11.2012 15:39, br...@apache.org wrote:
> >>> Author: brane
> >>> Date: Wed Nov 28 14:39:42 2012
> >>> New Revision: 1414728
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1414728&view=rev
> >>> Log:
> >>> Getting sidetracked for a bit: create placeholder and update build for
> >>> a future high-level C++ API for Subversion, based on the same
> principles
> >>> as JavaHL.
> >> Lest anyone become too worried about this: I'm not going to let this
> >> project divert my attention from getting 1.8 out the door. I had this
> >> idea on the back burner for a long time, and just now found a bit of
> >> time when I had to clear my head; so I decided to at least get the build
> >> infrastructure in place.
> > How does this compare to Hyrum's "object model"?
> >
> >   notes/object-model.txt
> >   ^/subversion/branches/object-model
>
> I don't know yet. I'll be looking at that more closely when the time
> comes, but I'll also take notes from JavaHL. I feel it's important that
> we hide the details of the C API (for example, its dependency on APR)
> from this high-level interface.


The object model stuff is probably a bit dated, but some of the ideas
probably still hold.  If there's anything I learned through that
experience, it was that we'll probably need to use something like pimpl for
any type of backward compatibility within the C++ bindings themselves.  Ugh.

-Hyrum

Re: reposurgeon now writes Subversion repositories

[Daniel Shahaf]

Branko Čibej wrote on Thu, Nov 29, 2012 at 13:41:34 +0100:
> On 29.11.2012 12:46, Eric S. Raymond wrote:
> > Daniel Shahaf :
> >>> Subversion's metadata doesn't have separate author and committer
> >>> properties, and doesn't store anything but a Unix user ID as
> >>> attribution.  I don't see any way around this.
> >> You're not fully informed, then.
> >>
> >> 1) svn:author revprops can contain any UTF-8 string.  They are not
> >> restricted to Unix user id's.  (For example, they can contain full
> >> names, if the administrator so chooses.)
> > Right.  At one point during the development of this feature I was
> > accidentally storing the full email field in this property.  So I
> > already knew that this is allowed at some level.  
> >
> > And, I have no trouble believing that svn log will cheerfully echo
> > anything that I choose to stuff in that field.  
> >
> > But...
> >
> > (1) How much work would it be it to set up a Subversion installation 
> > so that when I svn commit, the tool does the right thing, e.g. puts
> > a DVCS-style fullname/email string in there?
> 
> I don't know how common that practice is, but I've worked on a project
> where svn:author was filled in from the DN and e-mail attributes of an
> X-509 certificate. It's also quite easy to set svn:author from
> information stored in LDAP (that is, if you find anything about LDAP
> actually easy).
> 

Another option is to change the svn:author prop in the pre-commit hook.

> > RFC: If I wrote a patch that let Subversion users set their own
> > content string for the author field in ~/.subversion/config, would
> > you merge it?  Because I'd totally write that.
> 
> Hint: svn commit --with-revprop svn:author="Twizzle Strongpants
> "
> 
> I personally wouldn't mind if that were a user preference in the config
> file. It'd have to be a per-server config option, however; and even
> better, per-repository, which is a concept that the Subversion config
> file does not currently support. (There's a reason why I put my ID into
> .git/config, not ~/.gitconfig.)
> 
> Note that it's up to the server administrator to actually allow clients
> to set svn:author (and any other revision property). The assumed, and
> most common, configuration is that the server derives svn:author from
> authentication information.
> 

Specifically, the server code special-cases svn:author and svn:date ---
an administrator would have to use a pre-commit hook (or patch the
server) to avoid those being set from the authentication info and system
clock.

> [...]
> 
> >> You might also seek community consensus to reserve an svn:foo name for
> >> the "original author" property --- perhaps svn:original-author --- so
> >> that reposurgeon and other git->svn tools can interoperate in the way
> >> they transfer the "original author" information.
> > OK.  But I like the idea of letting the users set their own author
> > content string better.  Instead of another layer of kluges, why
> > shouldn't Subversion join the DVCSes in the happy land of
> > Internet-scoped attributions?
> 
> This discussion has come up before. Today, the assumption that
> svn:author is something that the server has verified (modulo admins'
> shenanigans) is pretty much cast in concrete.
> 
> I'm open to suggestions, up to and including breaking that assumption,
> though obviously I'd prefer not to.
> 
> -- Brane
> 
> 
> -- 
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
> 

Re: Regression tests FAILs with older format repositories

[Philip Martin]

Daniel Shahaf  writes:

> Philip Martin wrote on Wed, Nov 28, 2012 at 15:55:44 +:
>> -Warning: 'post-commit' hook failed with error output:
>> +Warning: post-commit hook failed (exit code 1) with output:
>> 
>> I've not investigated why the error message is different.
>
> Maybe it's the same code path and just the text of the error message
> got changed?

This is a user/testsuite problem: server-minor-version is really
designed for testing old servers, not old format repositories with new
servers.  The testsuite determines the expected error based on
server-minor-version and that doesn't work if using a new server with
old format repositories.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: reposurgeon now writes Subversion repositories

[Branko Čibej]

On 29.11.2012 12:46, Eric S. Raymond wrote:
> Daniel Shahaf :
>>> Subversion's metadata doesn't have separate author and committer
>>> properties, and doesn't store anything but a Unix user ID as
>>> attribution.  I don't see any way around this.
>> You're not fully informed, then.
>>
>> 1) svn:author revprops can contain any UTF-8 string.  They are not
>> restricted to Unix user id's.  (For example, they can contain full
>> names, if the administrator so chooses.)
> Right.  At one point during the development of this feature I was
> accidentally storing the full email field in this property.  So I
> already knew that this is allowed at some level.  
>
> And, I have no trouble believing that svn log will cheerfully echo
> anything that I choose to stuff in that field.  
>
> But...
>
> (1) How much work would it be it to set up a Subversion installation 
> so that when I svn commit, the tool does the right thing, e.g. puts
> a DVCS-style fullname/email string in there?

I don't know how common that practice is, but I've worked on a project
where svn:author was filled in from the DN and e-mail attributes of an
X-509 certificate. It's also quite easy to set svn:author from
information stored in LDAP (that is, if you find anything about LDAP
actually easy).

> (2) Have the tools been tested for bugs arising from having whitespace
> in that data?

Which tools? If you mean Subversion libs and command-line client, then yes.

> Really, if it's actually easy to set up DVCS-style globally unique IDs you
> Subversion guys ought to be shouting it from the housetops.  The absence
> of this capability is a serious PITA in several situations, including 
> for example migrating projects between forges.

Well, I find that we don't actually spell out anywhere that svn:author
can be pretty much any UTF-8 string. It can even contain newlines,
although that's not recommended.

> RFC: If I wrote a patch that let Subversion users set their own
> content string for the author field in ~/.subversion/config, would
> you merge it?  Because I'd totally write that.

Hint: svn commit --with-revprop svn:author="Twizzle Strongpants
"

I personally wouldn't mind if that were a user preference in the config
file. It'd have to be a per-server config option, however; and even
better, per-repository, which is a concept that the Subversion config
file does not currently support. (There's a reason why I put my ID into
.git/config, not ~/.gitconfig.)

Note that it's up to the server administrator to actually allow clients
to set svn:author (and any other revision property). The assumed, and
most common, configuration is that the server derives svn:author from
authentication information.

[...]

>> You might also seek community consensus to reserve an svn:foo name for
>> the "original author" property --- perhaps svn:original-author --- so
>> that reposurgeon and other git->svn tools can interoperate in the way
>> they transfer the "original author" information.
> OK.  But I like the idea of letting the users set their own author
> content string better.  Instead of another layer of kluges, why
> shouldn't Subversion join the DVCSes in the happy land of
> Internet-scoped attributions?

This discussion has come up before. Today, the assumption that
svn:author is something that the server has verified (modulo admins'
shenanigans) is pretty much cast in concrete.

I'm open to suggestions, up to and including breaking that assumption,
though obviously I'd prefer not to.

-- Brane


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

Re: Regression tests FAILs with older format repositories

[Philip Martin]

Philip Martin  writes:

> We are passing fspaths to a relpath function.  The test passes in 1.7
> because svn_relpath_skip_ancestor doesn't assert that the paths are
> relpaths and works if passed fspaths.

svn_relpath__is_child, not svn_relpath_skip_ancestor.

-- 
Philip

Re: Regression tests FAILs with older format repositories

[Philip Martin]

Julian Foad  writes:

> Philip Martin wrote:
>> The more significant fail
>> is:
>> 
>> $ ./fs-test --server-minor-version=4 34
>> lt-fs-test: ../src/subversion/libsvn_subr/dirent_uri.c:1456: 
>> svn_relpath_skip_ancestor: Assertion `relpath_is_canonical(parent_relpath)' 
>> failed.
>
> OK, I'll investigate that.

gdb shows:

Program received signal SIGABRT, Aborted.
(gdb) up 4
#4  0x766e650e in prev_location (prev_path=0x7fffe2c8, 
prev_rev=0x7fffe2d0, fs=0x77fef620, root=0x73f405e0, 
path=0x73f38728 "/A/D", pool=0x73f39028)
at ../src/subversion/libsvn_fs_fs/tree.c:3246
3246  remainder_path = svn_relpath_skip_ancestor(copy_path, path);
(gdb) p copy_path
$3 = 0x77e1068e "/A/D"
(gdb) p path
$4 = 0x73f38728 "/A/D"

We are passing fspaths to a relpath function.  The test passes in 1.7
because svn_relpath_skip_ancestor doesn't assert that the paths are
relpaths and works if passed fspaths.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: reposurgeon now writes Subversion repositories

[Eric S. Raymond]

Daniel Shahaf :
> > Subversion's metadata doesn't have separate author and committer
> > properties, and doesn't store anything but a Unix user ID as
> > attribution.  I don't see any way around this.
> 
> You're not fully informed, then.
> 
> 1) svn:author revprops can contain any UTF-8 string.  They are not
> restricted to Unix user id's.  (For example, they can contain full
> names, if the administrator so chooses.)

Right.  At one point during the development of this feature I was
accidentally storing the full email field in this property.  So I
already knew that this is allowed at some level.  

And, I have no trouble believing that svn log will cheerfully echo
anything that I choose to stuff in that field.  

But...

(1) How much work would it be it to set up a Subversion installation 
so that when I svn commit, the tool does the right thing, e.g. puts
a DVCS-style fullname/email string in there?  

(2) Have the tools been tested for bugs arising from having whitespace
in that data?

Really, if it's actually easy to set up DVCS-style globally unique IDs you
Subversion guys ought to be shouting it from the housetops.  The absence
of this capability is a serious PITA in several situations, including 
for example migrating projects between forges.

RFC: If I wrote a patch that let Subversion users set their own
content string for the author field in ~/.subversion/config, would
you merge it?  Because I'd totally write that.

> 2) You can define custom revision properties.  In your case, the easiest
> way would be to set an reposurgeon:author property, alongside the
> svn:author property.

Yeah, sure, I've assumed all along this wouldn't break if I tried it.
If I actually thought you guys were capable of designing a data model
with a perfectly general-looking store of key/value pairs and then
arbitrarily restricting the key set so I couldn't do that, I'd almost
have to find each and every one of you and kick your asses into next
Tuesday on account of blatant stupidity. I have no such plans :-).

But...what good does this capability do?  OK, it would assist
round-tripping back to gitspace, but while that's kind of cool I don't
see any help for a normal Subversion workflow here.
 
> You might also seek community consensus to reserve an svn:foo name for
> the "original author" property --- perhaps svn:original-author --- so
> that reposurgeon and other git->svn tools can interoperate in the way
> they transfer the "original author" information.

OK.  But I like the idea of letting the users set their own author
content string better.  Instead of another layer of kluges, why
shouldn't Subversion join the DVCSes in the happy land of
Internet-scoped attributions?

> How does reposurgeon handle empty directories with (node) properties?

Currently by ignoring all of them except svn:ignore, which it turns 
into .gitignore content on the gitspace side.  And now vice-versa, too.

Not clear what else it *could* do.  I'd take suggestions.

> >   Subversion has a concept of "flows"; that is, named segments of
> >   history corresponding to files or directories that are created when
> >   the path is added, cloned when the path is copied, and deleted when
> >   the path is deleted. This information is not preserved in import
> >   streams or the internal representation that reposurgeon uses.  Thus,
> >   after editing, the flow boundaries of a Subversion history may be
> >   arbitrarily changed.
> > 
> > This is me being obsessive about documenting the details.  I think it
> > is doubtful that most Subversion users even know flows exist.
> 
> I think you're saying that adds might turn into copies, and vice-versa.
> That is something users would notice --- it is certainly exposed in the
> UI --- even though node-id's are not exposed to clients.

I'm saying nobody thinks of flows when they do branch copies.  It's
not just that users don't see node IDs, it's that no part of most users'
mental model of how Subversion works resembles them.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: reposurgeon now writes Subversion repositories

[Branko Čibej]

On 29.11.2012 08:58, Daniel Shahaf wrote:
> I think you're saying that adds might turn into copies, and
> vice-versa. That is something users would notice --- it is certainly
> exposed in the UI --- even though node-id's are not exposed to clients. 

... yet. But there are plans underway to expose them.

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

Re: reposurgeon now writes Subversion repositories

[Daniel Shahaf]

Eric S. Raymond wrote on Thu, Nov 29, 2012 at 00:59:45 -0500:
>   In summary, Subversion repository histories do not round-trip through
>   reposurgeon editing. File content changes are preserved but some
>   metadata is unavoidably lost.  Furthermore, writing out a DVCS history
>   in Subversion also loses significant portions of its metadata.
> 
>   Writing a Subversion repository or dump stream discards author
>   information, the committer's name, and the hostname part of the commit
>   address; only the commit timestamp and the local part of the
>   committer's email address are preserved, the latter becoming the
>   Subversion author field.  However, reading a Subversion repository and
>   writing it out again will preserve the author fields.
> 
> Subversion's metadata doesn't have separate author and committer
> properties, and doesn't store anything but a Unix user ID as
> attribution.  I don't see any way around this.

You're not fully informed, then.

1) svn:author revprops can contain any UTF-8 string.  They are not
restricted to Unix user id's.  (For example, they can contain full
names, if the administrator so chooses.)

2) You can define custom revision properties.  In your case, the easiest
way would be to set an reposurgeon:author property, alongside the
svn:author property.

You might also seek community consensus to reserve an svn:foo name for
the "original author" property --- perhaps svn:original-author --- so
that reposurgeon and other git->svn tools can interoperate in the way
they transfer the "original author" information.

I note that one can set revision properties at commit time:

svn commit -m logmsg --with-revprop svn:original-author="Patch Submitter 
"

>   Empty directories aren't represented in import streams. Consequently,
>   reading and writing Subversion repositories preserves file content,
>   but not empty directories.  It is also not guaranteed that after
>   editing a Subverson repository that the sequence of directory
>   creations and deletions relative to other operations will be
>   identical; the only guarantee is that enclosing directories will be
>   created before any files in them are.

How does reposurgeon handle empty directories with (node) properties?

% svnadmin create r
% svnmucc -mm -U file://$PWD/r mkdir foo propset k v foo

>   Subversion has a concept of "flows"; that is, named segments of
>   history corresponding to files or directories that are created when
>   the path is added, cloned when the path is copied, and deleted when
>   the path is deleted. This information is not preserved in import
>   streams or the internal representation that reposurgeon uses.  Thus,
>   after editing, the flow boundaries of a Subversion history may be
>   arbitrarily changed.
> 
> This is me being obsessive about documenting the details.  I think it
> is doubtful that most Subversion users even know flows exist.
> 

I think you're saying that adds might turn into copies, and vice-versa.
That is something users would notice --- it is certainly exposed in the
UI --- even though node-id's are not exposed to clients.

> 

Cheers

Daniel