Re: latest svn book?

[Daniel Shahaf]

Todd Armstrong wrote on Wed, 19 Jul 2017 19:22 +:
> There’s a 1.8 draft in the nightly build section of that page with a 2016 
> copyright that I’ve been using.
> 
> It’s not available in PDF form yet, though.

Requests for a PDF version should be addressed to the book's mailing
list (svnbook-...@red-bean.com).

Re: Apache httpd 2.4 + Subversion 1.9.5 + LDAP combination does not work on CentOS 7.x

[Daniel Shahaf]

Nico Kadel-Garcia wrote on Wed, 19 Jul 2017 22:08 -0400:
> This subscriber is new, and having difficulty with Apache
> configurations. Since that's so often been so awkward, and this is
> *another* reason to migrate away from it, I made sure that *he*
> thought about the functional, less complex to integrate, and by
> default more secure svn+ssh.

Asking people whether they had considered svn+ssh:// would be reasonable.

Offering unbiased comparisons of svn+ssh:// and https:// would be reasonable.

Repeatedly preaching your personal preference, even in threads where use
of https:// is mentioned in passing, is not acceptable.  We have been asking
you for years to stop that, and we're asking you again now.

You are, of course, entitled to prefer whichever network protocol you wish,
and for that matter, you're entitled to run for Prime Minister / President 
on a platform outlawing the use of ra_serf.  We won't stop you from doing
any of that; we just ask you to take your preaching elsewhere and keep this
list as a source of unbiased advice.

Daniel

Re: Apache httpd 2.4 + Subversion 1.9.5 + LDAP combination does not work on CentOS 7.x

[Nico Kadel-Garcia]

On Wed, Jul 19, 2017 at 11:04 PM, Nathan Hartman
 wrote:
>> On Jul 19, 2017, at 10:08 PM, Nico Kadel-Garcia  wrote:
>>
>> Yup. I don't do it every week, or even every month. Frankly, as
>> Subversion has been falling in popularity,
>
> I think that's like the BSD is dying myth. While it's true that hype, Linus's 
> blessing, and the availability of GitHub have taken a big chunk of the F/OSS 
> world by storm, there are still plenty of people, projects, and businesses 
> that use Subversion. We recently evaluated other systems which shall remain 
> nameless just to make sure we're on top of goings on in our industry and our 
> experiences reaffirmed why we use Subversion. In a decade of use, zero 
> problems. It's mature, it does what it's supposed to do, and it's simple to 
> use. We like it. So do numerous other people.

I didn't say Subversion was dying. I said it was falling in
popularity, which is consistent with the surveys I can find. And dear
lordie, it's consistent with my professional and amateur software
development experience. I've seen *one* new repo started or built from
scratch under Subversion since 2006. I've seen approximately 1000
software projects or repos started or built from scratch under another
source control system, which shall remain unnamed but which hosts my
Subversion RPM building tools, I've also helped with roughly half a
dozen funded projects migrating *away* from Subversion in that time. I
help out new admins and users on the group out of appreciation, not
because it's funded or because the userbase is growing.

The local HTTP credential storage is a longstanding sore point, I
admit, which is why I *didn't* harp on it. I mentioned it as a
specific security issue, in passing, which a new HTTPS Subversion
administrator may not have considered. And I mentioned it as leverage
to migrate away away from the httpd server integration. The httpd
server integration has traditionally been one of the most awkward
parts of Subversion server support, as the original poster was
noticing quite painfully.

Re: 【wait on line】weird question about svnsync

[Nico Kadel-Garcia]

Better deduplicaton? And did you exclude old branches with bulky binaries
in them?

On Mon, Jun 26, 2017 at 7:07 AM, Dummy <3295285...@qq.com> wrote:

> dear subversion:
> I have a weird question about svnsync:
> i svnsync gzrepos(centos 6.4-svn1.6.11) to gz-mirror1(centos 7-svn1.9.5),
> when it was done successfully, i found that the mirror repo(gz-mirror1)
> is more less than source repo(gzrepos) in sizes ,the source repo(gzrepos)
> is *177G* while the mirror one(gz-mirror1)  is only *66G*
> for example: revision:2012,it seems to be compressed
> svnsync logs:
>
> however, the mirror repo(gz-mirror1)  seems OK, we can
> access,checkout,show log etc.
> i heard that subversion 1.9.5 has Optimized data format,but the gap is
> too large。
> I'm a little worried about the data，may i ask why?
> best wish
>

Re: Apache httpd 2.4 + Subversion 1.9.5 + LDAP combination does not work on CentOS 7.x

[Nathan Hartman]

On Thu, Jul 20, 2017 at 9:05 AM, Nico Kadel-Garcia  wrote:

> On Wed, Jul 19, 2017 at 11:04 PM, Nathan Hartman
>  wrote:
> >> On Jul 19, 2017, at 10:08 PM, Nico Kadel-Garcia 
> wrote:
> >>
> >> Yup. I don't do it every week, or even every month. Frankly, as
> >> Subversion has been falling in popularity,
> >
> > I think that's like the BSD is dying myth. [snip]
>
> I didn't say Subversion was dying. I said it was falling in
> popularity, which is consistent with the surveys I can find.
>

Thanks for clearing that up. It's unfortunate that you've seen those
effects. I really think they're due to the reasons I mentioned in the last
post, which are based on perception, not actual merit such as capability or
ease of use.

Is there potential for improvement? Always. But is it the terrible system
proponents of that other nameless system love to claim it is? Absolutely
not! I use a very simple test. This isn't rocket science: Ten years with
Subversion, ZERO problems since day one. With That Other System (tm)...
Well, we might be stupid. Maybe we are. But Subversion has never failed us.
Hype and perception notwithstanding, that says a lot to me.

svn vs. git

[Johan Corveleyn]

Not wanting to start a flame war, but for all svn users and admins out
there that sometimes need to have this conversation ... I found this to be
a very nice website:

https://svnvsgit.com

(I'm not affiliated with the website, just ran into it)

-- 
Johan

Re: svn vs. git

[Nathan Hartman]

On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn  wrote:

> Not wanting to start a flame war, but for all svn users and admins out
> there that sometimes need to have this conversation ... I found this to be
> a very nice website:
>
> https://svnvsgit.com
>
> (I'm not affiliated with the website, just ran into it)
>

Thank you! Thank you! Thank you!

I did recently have this conversation and this website could have helped
significantly.

There seem to be some comparisons out there that are comparing DVCSs
against ancient versions of Subversion. Probably those comparisons are old
and therefore their argument may have been valid at the time. But if those
comparisons are more recent, then there's a problem. Either the person
making the comparison is honestly unaware of progress made in Subversion's
development over the years, or they are deliberately comparing to old
versions to make Subversion look bad.

Regardless of how or why, I think the perception out there is just plain
wrong. I think Subversion is due a lot more credit than it gets. As I
mentioned in another thread (which may have prompted this one), we recently
evaluated other systems. We did not do this out of desire to migrate away
from Subversion; rather we did it in order to understand what's happening
in our industry, and as such we wanted to answer the question: will
switching to something else give us some new advantage? We gave git and
others a fair chance, and based on various technical, usability, and
management criteria we reached the conclusion that Subversion has been and
still is the best system for us. We manage all sorts of data with it, not
just program code.

While I'm here, I'll comment on a couple of significant issues mentioned at
that site.

Item #7 mentions the issue of a single monolithic repository vs numerous
smaller repositories, and the atomic whole-project commit, consistent
branches, and large-scale rafactoring made possible by it. These are
extremely important to us. We have numerous components whose history and
state must remain matched as they evolve. With the monolithic repository,
this happens by definition. Losing that by breaking things up into multiple
repositories (to avoid cloning a gigantic monolithic repo for every working
copy) would push a maintenance burden to everyone on our team, which is
unacceptable from a management perspective.

Item #11 mentions the issue of immutable history. We know from experience
that the ability to reproduce the exact bits at a point in time is crucial
to us. With Subversion, this very significant requirement is fulfilled, and
tremendous problems we had in our pre-Subversion days have disappeared.
Losing immutable history would be a huge step backwards for us.

One myth that is not mentioned on that page is the famous, "But you can't
work offline!" Being able to work "offline" is supposed to be the biggest
selling point of a DVCS over a CVCS. Okay... I'm calling that a myth. First
of all, there is nothing inherent to Subversion that "prevents" you from
working offline. You can work, you just can't do server side operations. Is
that such a big deal? And if it is, do you mean to tell me that in this day
and age of cloud services and IoT, where every single thing you do requires
Internet access, that you're ever really "offline" for long enough that it
matters? And even if you are planning to spend a year alone on a deserted
island, nothing stops you from doing "svnadmin create" on your local
computer and making as many commits as you want. But that doesn't make
sense, because the longer you work in isolation, the less likely it is that
your work will merge cleanly when you get back. Even the smartest and
greatest DVCS in the world can't solve that problem. So this "offline"
nonsense is a myth.

Subversion is a very good system. It doesn't get the credit it deserves,
and that needs to change. Those of us who love it should give it some good
PR and try to drum up more support for it.

RE: svn vs. git

[Scott Aron Bloom]

From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Thursday, July 20, 2017 14:39
To: Subversion 
Subject: Re: svn vs. git

On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn 
mailto:jcor...@gmail.com>> wrote:
Not wanting to start a flame war, but for all svn users and admins out there 
that sometimes need to have this conversation ... I found this to be a very 
nice website:

https://svnvsgit.com

(I'm not affiliated with the website, just ran into it)

Thank you! Thank you! Thank you!

I did recently have this conversation and this website could have helped 
significantly.

There seem to be some comparisons out there that are comparing DVCSs against 
ancient versions of Subversion. Probably those comparisons are old and 
therefore their argument may have been valid at the time. But if those 
comparisons are more recent, then there's a problem. Either the person making 
the comparison is honestly unaware of progress made in Subversion's development 
over the years, or they are deliberately comparing to old versions to make 
Subversion look bad.

Regardless of how or why, I think the perception out there is just plain wrong. 
I think Subversion is due a lot more credit than it gets. As I mentioned in 
another thread (which may have prompted this one), we recently evaluated other 
systems. We did not do this out of desire to migrate away from Subversion; 
rather we did it in order to understand what's happening in our industry, and 
as such we wanted to answer the question: will switching to something else give 
us some new advantage? We gave git and others a fair chance, and based on 
various technical, usability, and management criteria we reached the conclusion 
that Subversion has been and still is the best system for us. We manage all 
sorts of data with it, not just program code.

While I'm here, I'll comment on a couple of significant issues mentioned at 
that site.

Item #7 mentions the issue of a single monolithic repository vs numerous 
smaller repositories, and the atomic whole-project commit, consistent branches, 
and large-scale rafactoring made possible by it. These are extremely important 
to us. We have numerous components whose history and state must remain matched 
as they evolve. With the monolithic repository, this happens by definition. 
Losing that by breaking things up into multiple repositories (to avoid cloning 
a gigantic monolithic repo for every working copy) would push a maintenance 
burden to everyone on our team, which is unacceptable from a management 
perspective.

Item #11 mentions the issue of immutable history. We know from experience that 
the ability to reproduce the exact bits at a point in time is crucial to us. 
With Subversion, this very significant requirement is fulfilled, and tremendous 
problems we had in our pre-Subversion days have disappeared. Losing immutable 
history would be a huge step backwards for us.

One myth that is not mentioned on that page is the famous, "But you can't work 
offline!" Being able to work "offline" is supposed to be the biggest selling 
point of a DVCS over a CVCS. Okay... I'm calling that a myth. First of all, 
there is nothing inherent to Subversion that "prevents" you from working 
offline. You can work, you just can't do server side operations. Is that such a 
big deal? And if it is, do you mean to tell me that in this day and age of 
cloud services and IoT, where every single thing you do requires Internet 
access, that you're ever really "offline" for long enough that it matters? And 
even if you are planning to spend a year alone on a deserted island, nothing 
stops you from doing "svnadmin create" on your local computer and making as 
many commits as you want. But that doesn't make sense, because the longer you 
work in isolation, the less likely it is that your work will merge cleanly when 
you get back. Even the smartest and greatest DVCS in the world can't solve that 
problem. So this "offline" nonsense is a myth.

Subversion is a very good system. It doesn't get the credit it deserves, and 
that needs to change. Those of us who love it should give it some good PR and 
try to drum up more support for it.

Having been coding using version code for way too long, I started with rcs, 
moved to CVS and am now firmly in the svn camp.

I was forced by a third party company to work with them on a github based 
project.  Boy was it painful…  But I must say, one thing I did LIKE  was the 
“offline” mode, of commit vs push.

To me, it would be interesting and a very nice enhancement to enable this into 
subversion.  Though I haven’t fully thought out the full flow, it would also 
HAVE to be optional.

But, I would very much like to be able to “check in to my personal area” while 
on a plane.  Do a diff/log against that area, and then when I feel the code is 
ready to check into the branch where I check out  against, I could “push” all 
the changes to the server.

Now, to do the same thing, I have to create either a branch o

Re: 【wait on line】weird question about svnsync

[Eric Johnson]

This could be for a number of reasons. Perhaps your original repository is
an older format? If that's the case, and your mirror is a newer format,
then the newer format could be packing and finding binary duplicates much
more effectively than is possible using the older format.

Eric.


On Thu, Jul 20, 2017 at 6:07 AM, Nico Kadel-Garcia  wrote:

> Better deduplicaton? And did you exclude old branches with bulky binaries
> in them?
>
> On Mon, Jun 26, 2017 at 7:07 AM, Dummy <3295285...@qq.com> wrote:
>
>> dear subversion:
>> I have a weird question about svnsync:
>> i svnsync gzrepos(centos 6.4-svn1.6.11) to gz-mirror1(centos 7-svn1.9.5),
>> when it was done successfully, i found that the mirror repo(gz-mirror1)
>> is more less than source repo(gzrepos) in sizes ,the source
>> repo(gzrepos) is *177G* while the mirror one(gz-mirror1)  is only *66G*
>> for example: revision:2012,it seems to be compressed
>> svnsync logs:
>>
>> however, the mirror repo(gz-mirror1)  seems OK, we can
>> access,checkout,show log etc.
>> i heard that subversion 1.9.5 has Optimized data format,but the gap is
>> too large。
>> I'm a little worried about the data，may i ask why?
>> best wish
>>
>
>

Re: svn vs. git

[Daniel Becroft]

We did a similar comparison as well, and again stuck with SVN. However,
this was predominantly due to the challenge of getting devs to relearn a
whole new process (we had enough trouble migrating from lock-modify-unlock
to a checkout/modify/commit workflow).

We did like the off-line process, and the ability to stash/unstash changes,
and the speed performance was immense.

The biggest advantage that we saw git giving us is integration with third
party apps out of the box. The number of vendors who have added git
integration into their apps far outpace the SVN integration, and it makes
it hard to stick with SVN when we can't take full advantage of these
systems. Code review is the main one, but this is driven by github.com more
than git itself, I guess.

I'm not sure what changes something like SVN 2.0 would bring, given that
the entirety of git's lifetime is wholly contained with SVN 1.x's, but it
will be interesting. I'm sure the devs are looking/investigating that.

On Fri., 21 Jul. 2017, 08:01 Scott Aron Bloom,  wrote:

>
>
>
>
> *From:* Nathan Hartman [mailto:hartman.nat...@gmail.com]
> *Sent:* Thursday, July 20, 2017 14:39
> *To:* Subversion 
> *Subject:* Re: svn vs. git
>
>
>
> On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn 
> wrote:
>
> Not wanting to start a flame war, but for all svn users and admins out
> there that sometimes need to have this conversation ... I found this to be
> a very nice website:
>
>
>
> https://svnvsgit.com
>
>
>
> (I'm not affiliated with the website, just ran into it)
>
>
>
> Thank you! Thank you! Thank you!
>
>
>
> I did recently have this conversation and this website could have helped
> significantly.
>
>
>
> There seem to be some comparisons out there that are comparing DVCSs
> against ancient versions of Subversion. Probably those comparisons are old
> and therefore their argument may have been valid at the time. But if those
> comparisons are more recent, then there's a problem. Either the person
> making the comparison is honestly unaware of progress made in Subversion's
> development over the years, or they are deliberately comparing to old
> versions to make Subversion look bad.
>
>
>
> Regardless of how or why, I think the perception out there is just plain
> wrong. I think Subversion is due a lot more credit than it gets. As I
> mentioned in another thread (which may have prompted this one), we recently
> evaluated other systems. We did not do this out of desire to migrate away
> from Subversion; rather we did it in order to understand what's happening
> in our industry, and as such we wanted to answer the question: will
> switching to something else give us some new advantage? We gave git and
> others a fair chance, and based on various technical, usability, and
> management criteria we reached the conclusion that Subversion has been and
> still is the best system for us. We manage all sorts of data with it, not
> just program code.
>
>
>
> While I'm here, I'll comment on a couple of significant issues mentioned
> at that site.
>
>
>
> Item #7 mentions the issue of a single monolithic repository vs numerous
> smaller repositories, and the atomic whole-project commit, consistent
> branches, and large-scale rafactoring made possible by it. These are
> extremely important to us. We have numerous components whose history and
> state must remain matched as they evolve. With the monolithic repository,
> this happens by definition. Losing that by breaking things up into multiple
> repositories (to avoid cloning a gigantic monolithic repo for every working
> copy) would push a maintenance burden to everyone on our team, which is
> unacceptable from a management perspective.
>
>
>
> Item #11 mentions the issue of immutable history. We know from experience
> that the ability to reproduce the exact bits at a point in time is crucial
> to us. With Subversion, this very significant requirement is fulfilled, and
> tremendous problems we had in our pre-Subversion days have disappeared.
> Losing immutable history would be a huge step backwards for us.
>
>
>
> One myth that is not mentioned on that page is the famous, "But you can't
> work offline!" Being able to work "offline" is supposed to be the biggest
> selling point of a DVCS over a CVCS. Okay... I'm calling that a myth. First
> of all, there is nothing inherent to Subversion that "prevents" you from
> working offline. You can work, you just can't do server side operations. Is
> that such a big deal? And if it is, do you mean to tell me that in this day
> and age of cloud services and IoT, where every single thing you do requires
> Internet access, that you're ever really "offline" for long enough that it
> matters? And even if you are planning to spend a year alone on a deserted
> island, nothing stops you from doing "svnadmin create" on your local
> computer and making as many commits as you want. But that doesn't make
> sense, because the longer you work in isolation, the less likely it is that
> your work will mer

Re: svn vs. git

[Paul Hammant]

>
>  Code review is the main one, but this is driven by github.com more than
> git itself, I guess.
>

That was the game changer

wasn't it. Github's platform had built in code-review with the pull request
concept from their public launch (2008). That raised the bar, and all
portals had to have built in code review after that.  Of course Google had
this first with their Mondrian code review system (2006 if not before), but
that wasn't available to use mortals. Anecdotally GitHub implement their
code review in Postgres. I'd prefer to see it backed by source control,
which I touch on 2/3 of the way through this

article.

- Paul

Re: svn vs. git

[Evan Driscoll]

On Thu, Jul 20, 2017 at 4:38 PM, Nathan Hartman
 wrote:
> On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn  wrote:
>>
>> Not wanting to start a flame war, but for all svn users and admins out
>> there that sometimes need to have this conversation ... I found this to be a
>> very nice website:
>>
>> https://svnvsgit.com
>>
>> (I'm not affiliated with the website, just ran into it)

While it has a lot of good information, I also don't find it
particularly unbiased; the points are all chosen to make Subversion
look better than in many comparisons (without bringing up other points
of comparison where Git really does come out on top), and some where
the headings are neutral are still written that way. For example,
"DVCS may be great for certain projects, but they have a number of
limitations that become roadblocks for others: no access control, full
copy of repository on every computer, no exclusive files locks and so
on" but no list of places where centralized systems fall down, or why
DVCSs very often shine for open source development for example. I also
think that the "Git history is not safe" point is vastly overstated;
not only that, but if you want me to name a version control command
that I think has the absolute worst combination of frequency of use
and destructiveness, it is 'svn up'.

The list I think makes a good rebuttal to common arguments, but it
doesn't make for a fair comparison overall.

And I'm not some Subversion hater either. I use Git for my personal
projects, but we use Subversion at work and I'm fine with it most of
the time. (I do *really* miss rebasing and the index. I actually wrote
a script [1] to make something that acts like 'git commit --patch',
but it's a shadow of how well the index works.) Git would actually be
hard for us to transition to, because we mostly use the "one big
monorepo" organization. That makes even me very hesitant to push for a
change; I fear that it would bring much more annoyances than
improvements.

[1] https://github.com/EvanED/svn-commit-patch

I did want to hit on this point though:

> One myth that is not mentioned on that page is the famous, "But you can't
> work offline!" Being able to work "offline" is supposed to be the biggest
> selling point of a DVCS over a CVCS. Okay... I'm calling that a myth. First
> of all, there is nothing inherent to Subversion that "prevents" you from
> working offline. You can work, you just can't do server side operations. Is
> that such a big deal? And if it is, do you mean to tell me that in this day
> and age of cloud services and IoT, where every single thing you do requires
> Internet access, that you're ever really "offline" for long enough that it
> matters?

For me: not right now, but a few years ago, an unqualified YES. And
it's only not true now by virtue of the location my company moved to
when we changed offices.

A few years ago, I commuted to "work" (well, grad school) by bus;
about a 30 minute trip each way. I often tried to get work done on
that bus ride. So what do I do when 10 minutes into the trip, I have
something I want to commit?

I was doing work on projects that were, at the time, in Subversion,
and that situation is a PITA. You have a choice between (1) say "screw
it" and make crappy monolithic commits of "did this thing and that
thing and this other totally unrelated thing", (2) juggle around
patchfiles, which gets you what you want but is pretty manually
intensive, or (3) get to that point and stop working. I usually did
(3). (Eventually I did (4), which is lobby enough to move that project
to Git.)

I'm probably a bit of an edge case here; I suspect most people don't
take transit, and many that do have either fancy busses with wifi or
can tether to a cell phone. And it doesn't even affect me any more.

But don't dismiss that use case.

(You can also think people who do a fair bit of travelling --
airports, on the planes, etc.)

Evan

Re: svn vs. git

[Xin LI]

Since the article mentioned FreeBSD (I'm a FreeBSD developer, and I
use both git and subversion everyday), I think I need to point out
that the author have missed some important pain points.

My biggest pain point with subversion is that 'svn up', 'svn st' and
'svn diff' take much longer time compared to git's counterpart ('git
pull', 'git st', and 'git diff') for FreeBSD's base/ (src) and ports/
(ports) trees.

As a result, doing merges across branches with subversion could become
quite painful with FreeBSD's branch usage, where branches tends to be
diverged quite a bit (we have multiple "-STABLE" branches, and
sometimes changes are not backported from trunk to these branches).
Because the tree is large, 'svn merge' operation is slow compared to
the git counterpart (git cherry-pick, except it does not keep the
mergeinfo this way), and doing multiple merges would require the
repository server (or a local mirror), and most importantly, if
something goes wrong in the middle, there is no easy way to recover
from it.  Here is an example, let's say I have a list of 5 commits to
be merged, and the first one have a conflict that requires manual
tweaks, then I would merge 2-5, and at 5 I saw another conflict and
noticed that there is one additional commit that was missing, I have
to start over.  With git, the work is easier because the first 4
changes are cherry-picked as local commits, and it's quite easy to
reorder or insert commits with 'git rebase'.

I think svn have its advantages, and I like the way it keeps track of
mergeinfo, etc., and use of a centralized repository would give the
developer a very quick idea of where they are at, however, these
benefits doesn't really overweight the fast "everyday" operations that
git offers.

As far as I know, many FreeBSD developers actually uses git as a patch
manager for their everyday development with git-svn or our github
export, and commit with svn when the changes are ready to get landed.
In my previous work (on FreeNAS), we used git almost exclusively
(other than upstreaming changes back to FreeBSD, we don't use
subversion at all).

Cheers,

On Thu, Jul 20, 2017 at 12:41 PM, Johan Corveleyn  wrote:
> Not wanting to start a flame war, but for all svn users and admins out there
> that sometimes need to have this conversation ... I found this to be a very
> nice website:
>
> https://svnvsgit.com
>
> (I'm not affiliated with the website, just ran into it)
>
> --
> Johan

Re: svn vs. git

[Branko Čibej]

On 21.07.2017 00:01, Scott Aron Bloom wrote:
>
> I was forced by a third party company to work with them on a github
> based project.  Boy was it painful…  But I must say, one thing I did
> *LIKE * was the “offline” mode, of commit vs push.
>
>  
>
> To me, it would be interesting and a very nice enhancement to enable
> this into subversion.  Though I haven’t fully thought out the full
> flow, it would also HAVE to be optional.
>

I suggest you move over to the dev@ list. A prototype implementation of
this feature is happening as we speak. User input and design review
would be very helpful.

You could start reading here:
https://lists.apache.org/thread.html/827004aa53c900379afe10d8ae721fc1b6fd6a133400033606b071e4@%3Cdev.subversion.apache.org%3E
https://lists.apache.org/thread.html/52da79c673d804dfbfd98a9d18ab2ed3d772e04c32afbabfdd29e344@%3Cdev.subversion.apache.org%3E

-- Brane