svn vs. git

[Johan Corveleyn <jc...@gmail.com>]

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

[Evan Driscoll <ev...@gmail.com>]

On Thu, Jul 20, 2017 at 4:38 PM, Nathan Hartman
<ha...@gmail.com> wrote:
> On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jc...@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)

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

[Paul Hammant <pa...@hammant.org>]

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

That was the game changer
<https://trunkbaseddevelopment.com/game-changers/#github-s-entire-platform-2008-onwards>
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
<https://paulhammant.com/2014/11/13/code-review-the-unit-of-work-should-be-a-single-commit/>
article.

- Paul

Re: svn vs. git

[Daniel Becroft <dj...@gmail.com>]

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, <sc...@towel42.com> wrote:

>
>
>
>
> *From:* Nathan Hartman [mailto:hartman.nathan@gmail.com]
> *Sent:* Thursday, July 20, 2017 14:39
> *To:* Subversion <us...@subversion.apache.org>
> *Subject:* Re: svn vs. git
>
>
>
> On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jc...@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 of a branch
> (or a throw away branch from trunk) on the server.  And check in there,
> until ready to merge onto top of trunk or the brank.
>
> The problem, is you have to be online to do this.
>
> Soctt
>

Re: svn vs. git

[Branko Čibej <br...@apache.org>]

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

RE: svn vs. git

[Scott Aron Bloom <sc...@towel42.com>]

From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
Sent: Thursday, July 20, 2017 14:39
To: Subversion <us...@subversion.apache.org>
Subject: Re: svn vs. git

On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jc...@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 of a branch (or a throw away branch from trunk) on the server.  And check in there, until ready to merge onto top of trunk or the brank.

The problem, is you have to be online to do this.

Soctt

Re: svn vs. git

[Stefan Sperling <st...@elego.de>]

On Tue, Jul 25, 2017 at 08:48:07AM +0200, Andreas Krey wrote:
> This also means that I can't maintain a patched version of
> svn (or anything in an svn repo) without having commit
> privilege to the source repo

This is obviously true, and a reason for why the Subversion project
itself has a very relaxed commit access policy. Need a branch?
Just show a nice diff to any full committer and they can make it happen:
https://subversion.apache.org/docs/community-guide/roles.html#partial-commit-access

Granted, this is still an extra hoop you might not want to jump through,
in which case using a git mirror simply makes more sense.

And other projects using SVN may be less open about this, of course.
The point is that people don't need to be walled off still stands.
It is a process problem, not a technical one, unless you're working
at Linux kernel scale with a community of thousands across various
organizations, which Subversion was never intended for.
You might remember the page on subversion.tigris.org around the time
git was first created, which asked people to stop suggesting that Linus
should use SVN: https://svn.apache.org/repos/asf/subversion/branches/1.2.x/www/subversion-linus.html

Re: svn vs. git

[Stefan Sperling <st...@elego.de>]

On Tue, Jul 25, 2017 at 01:59:29PM +0200, Johan Corveleyn wrote:
> It even has internal libraries with stable API's that
> allow writing plugins and GUI's on top rather than them having to drive a
> command line utility.

This is something git developers who I know personally *really want*.
Unfortunately it's hard to get there when starting from a pile of
perl scripts and tiny C utils with main() functions :-/

Nothing is perfect.

Re: svn vs. git

[Nathan Hartman <ha...@gmail.com>]

On Tue, Jul 25, 2017 at 2:48 AM, Andreas Krey <a....@gmx.de> wrote:

> On Thu, 20 Jul 2017 17:38:38 +0000, Nathan Hartman wrote:
> ...
> > Is that such a big deal?
>
> The big deal is a slightly different point. Making commit 'offline'
> not only allows me to make commits while in the middle of nowhere
> (and here in germany this easily includes trains).
>

Quite a few people seem to be working on trains during their commute. I
have to say that I've never been able to concentrate with so much noise,
motion, and distraction going on, and I don't see myself able to produce
one coherent commit let alone more than one. I once worked in a car for one
hour to solve a customer emergency. For some reason, looking at my computer
screen while in a moving vehicle made me dizzy for hours afterwards. The
code I wrote worked (miraculously) but on further examination after the
fact, it was some of the most atrocious code I've ever seen. Kudos to all
who can get real work done while on board a plane, train, or automobile. :-)

Re: svn vs. git

[Johan Corveleyn <jc...@gmail.com>]

Op 25 jul. 2017 9:48 a.m. schreef "Andreas Krey" <a....@gmx.de>:

On Thu, 20 Jul 2017 17:38:38 +0000, Nathan Hartman wrote:
...

> Subversion is a very good system. It doesn't get the credit it deserves,

Please. git managed to be faster in providing actually working
(i.e. tracked) merges than subversion, and then there was
the --reintegrate debacle that took another five years to
sort out.


Please. svn managed to be faster in providing granular access control,
sparse checkouts, handling large repositories and is *vastly* more simple
to use than git. It even has internal libraries with stable API's that
allow writing plugins and GUI's on top rather than them having to drive a
command line utility.

So ... it depends what you're after. git being faster at having tracked
merges doesn't make Subversion a bad system.

-- 
Johan

Re: svn vs. git

[Andreas Krey <a....@gmx.de>]

On Thu, 20 Jul 2017 17:38:38 +0000, Nathan Hartman wrote:
...
> 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.

In other words, you have a versioning system that you can't use offline,
except for local diffs.

> Is that such a big deal?

The big deal is a slightly different point. Making commit 'offline'
not only allows me to make commits while in the middle of nowhere
(and here in germany this easily includes trains).

It also allows me to make commits for a repo that I don't have
commit privileges for - I can commit my work in a meaningful way,
and later convince one of the official committers to pull these.

This also means that I can't maintain a patched version of
svn (or anything in an svn repo) without having commit
privilege to the source repo, or having to do the
vendor branch dance (with in itself is unnecessarily
annoying in svn).

> 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?

It also makes a difference in speed - git log usually outputs data
faster than anybody can open an SSL connection in edge land.

...

> 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.

You know that that is a straw man. There is no in-svn way to
reconcile that with another repo, and also I don't want to
start on an empty repo, but, say, on the current svn trunk.

> 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.

That is also orthogonal. Being offline does not mean that other people
work in the same repo, let alone area of a product. Also, the alternative,
namely working on trunk and do frequent updates, is worse in comparison,
because then you end up in conflicts in you sandbox, and have no way
of backing out and trying again later.

> Even the smartest and
> greatest DVCS in the world can't solve that problem.

Neither can non-distributed systems. The question is how long
you let work diverge, not where you do it.

> Subversion is a very good system. It doesn't get the credit it deserves,

Please. git managed to be faster in providing actually working
(i.e. tracked) merges than subversion, and then there was
the --reintegrate debacle that took another five years to
sort out.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: svn vs. git

[Nathan Hartman <ha...@gmail.com>]

On Sun, Jul 23, 2017 at 4:21 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:

> Circling back to the original point. Local commits for Subversion,
>
effectively transforming it to a DVCS or distributed version control
> system, could be very cool.


You really should head over to dev@ and provide your thoughts on the [RFC]
Shelving and Checkpointing thread.

Personally I think Subversion should stay Subversion and not become git.
That is, it should stay centralized version control, because it is simple,
effective, and comes with all the advantages described earlier in this
thread. With the addition of these two local features, you could work
"offline," construct a complex commit in multiple steps, use it as a local
"undo/redo," and use it as an alternative to short-lived bug fix or feature
branches. While git-svn already makes this and much more possible,
advantages to staying within Subversion include: easier learning curve,
simplicity, and a more coherent solution.

Re: svn vs. git

[Nico Kadel-Garcia <nk...@gmail.com>]

On Sun, Jul 23, 2017 at 4:02 AM, Branko Čibej <br...@apache.org> wrote:
> On 23.07.2017 07:54, Nathan Hartman wrote:
>> On Jul 22, 2017, at 10:19 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>>>> I can glance at it if I can find some cycles, no promises. I'm leery:
>>> much of Subversion's support that I've seen, and that I've sold
>>> Subversion migration work with myself, is that the singular repository
>>> can be used to force developers to commit their work daily, to gather
>>> some idea if they're actually working on their projects, and avoid
>>> them squirreling away their work without code review or consistency
>>> checks against the main development branch. Been there, done that with
>>> personnel keeping git branches on their personal laptops or personal
>>> VM's and being horrified with later merges or even with what I found
>>> out they were doing later. It's enormous fun when an employee says
>>> "I've already done that" but somehow has never published their code
>>> anywhere that other people can see the work.
>> That's a legitimate concern. It could be partly addressed by adding an analytics feature. That's a buzzword and could generate some hype as a side benefit. There are already plenty of "analytics" features in Subversion (like blame) and perhaps what's needed is a python script that looks at the last day, week, and month, and spits out a report on how much and how often each user has contributed in those time frames.
>
>
> And so on ... such tools do exist. But no amount of tooling can replace
> communication. If a team leader can't get info out of her team members,
> no version control system is going to make her any wiser. Or the project
> any less a monumental failure.

Oh, this is getting into development philosophy and practices. The
team leader may not *care* about this information, it may only be the
concern of developers whose work overlaps with that of the secretive
developer.  Or the team leader may be the sinner who refuses to commit
their work because "it's not ready for release" or "not ready for
review", and causes compatibility branches with either subversion or
git. I've had good success with git encouraging developers to clone
their own personal repository up at github, making their changes to
branches there, and leaving them visible to see the day's work. But
good workflow, whether with git or Subversion, is hardly the only
reason a project can fail or even succeed despite poor source control
practices.

I've even seen some principal developers, especially those titled
"architect", who keep their work offline before they publish it
because no one else *does* understand it, and burning the time
educating them would make everyone miss release dates. I've even been
hired to clean up after years of that kind of practice, especially
coupled with "I don't document, if you have a question just ask" and
"the actual code is the only possible documentation, comments just
lead to confusion". It's an art form.

Circling back to the original point. Local commits for Subversion,
effectively transforming it to a DVCS or distributed version control
system, could be very cool. I'm concerned that it would eliminate one
of the features most critical to Subversion, forcing all commits to be
recorded on the central repository. If it's some intermediate solution
with new technologies and workflows, I'm uncertain of the benefits
when git-svn works reasonably well.

Re: svn vs. git

[Branko Čibej <br...@apache.org>]

On 23.07.2017 07:54, Nathan Hartman wrote:
> On Jul 22, 2017, at 10:19 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>>> I can glance at it if I can find some cycles, no promises. I'm leery:
>> much of Subversion's support that I've seen, and that I've sold
>> Subversion migration work with myself, is that the singular repository
>> can be used to force developers to commit their work daily, to gather
>> some idea if they're actually working on their projects, and avoid
>> them squirreling away their work without code review or consistency
>> checks against the main development branch. Been there, done that with
>> personnel keeping git branches on their personal laptops or personal
>> VM's and being horrified with later merges or even with what I found
>> out they were doing later. It's enormous fun when an employee says
>> "I've already done that" but somehow has never published their code
>> anywhere that other people can see the work.
> That's a legitimate concern. It could be partly addressed by adding an analytics feature. That's a buzzword and could generate some hype as a side benefit. There are already plenty of "analytics" features in Subversion (like blame) and perhaps what's needed is a python script that looks at the last day, week, and month, and spits out a report on how much and how often each user has contributed in those time frames.


And so on ... such tools do exist. But no amount of tooling can replace
communication. If a team leader can't get info out of her team members,
no version control system is going to make her any wiser. Or the project
any less a monumental failure.

-- Brane

Re: svn vs. git

[Nathan Hartman <ha...@gmail.com>]

On Jul 22, 2017, at 10:19 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>> I can glance at it if I can find some cycles, no promises. I'm leery:
> much of Subversion's support that I've seen, and that I've sold
> Subversion migration work with myself, is that the singular repository
> can be used to force developers to commit their work daily, to gather
> some idea if they're actually working on their projects, and avoid
> them squirreling away their work without code review or consistency
> checks against the main development branch. Been there, done that with
> personnel keeping git branches on their personal laptops or personal
> VM's and being horrified with later merges or even with what I found
> out they were doing later. It's enormous fun when an employee says
> "I've already done that" but somehow has never published their code
> anywhere that other people can see the work.

That's a legitimate concern. It could be partly addressed by adding an analytics feature. That's a buzzword and could generate some hype as a side benefit. There are already plenty of "analytics" features in Subversion (like blame) and perhaps what's needed is a python script that looks at the last day, week, and month, and spits out a report on how much and how often each user has contributed in those time frames. Perhaps it could calculate ratio of time between commits to combined size of patch plus log message, to try and ascertain if someone is actually committing their work. That's just an example to illustrate. I'm not saying it actually makes sense -- I know that you could spend weeks tracking down a one-character bug. And yes this comes with every imaginable caveat not least of which is that users will play the system if they know what their boss is measuring, but as a project manager you understand that this is a human problem and a management challenge and not something that technology can solve for you. What technology can do is number crunch to sort out the data and help you detect potential problem areas.

As an argument in favor of local shelving and checkpointing, while git-svn is perfectly legitimate, git is heavy artillery and git-svn requires working with and understanding both systems. That's okay for some people but others would like to stay within Subversion. It reduces various barriers to entry. If done well it would be opt-in, meaning that you would use Subversion exactly as before, but if you want the local features, they'd be there for you. That said, one idea I floated at dev@ was that "svn up" could automatically make an implied checkpoint before updating, so that you'd be guaranteed never to lose anything should incoming changes mess up your work. That fits well with Subversion's overall concept in my opinion.

Just my 2 cents :-)

Re: svn vs. git

[Nico Kadel-Garcia <nk...@gmail.com>]

On Sat, Jul 22, 2017 at 6:06 AM, Johan Corveleyn <jc...@gmail.com> wrote:

> Yeah, well, we know the lack of 'obliterate' is one of your favourite
> complaints about svn. I am not bothered by it at all, and so are many other
> svn users. But okay.
>
> You do realise git repositories get cloned, right? So once your password
> file or iso gets pulled / pushed it will be very hard to obliterate ... It's
> distributed VC after all, so you have a lot more repositories to worry about
> than just one.

Certainly I realize this. The segregation of commits to the local,
working copy, and the separate publication to a potential centralized
repository (such as github) is a very real workflow difference that
allows an erroneous local commit with git to be cleared, even
scratched, from the local repository and local history, before it gets
published upstream for broader publicaton. Under the common Subversion
model of "thou shalt not modify history", it can't be cleared at all
except with the quite fraught procedure of a full "svnadmin dump,
filter the dump, reload and rebuild a new upstream repo and pray you
didn't make any dangerous mistakes".

Been there, done that. I could tell stories, suffice to say that the
ability to scrub history has proven useful. The accidental inclusion
of sensitive data is one issue aided, though not completely solved
this way due to possible copies. The preserved and immutable history
of bulky and unnecessary content, that's another one.

> Okay, your other criticism is lack of local commits, which was also made by
> some other people in this thread, and that's certainly an area where svn
> needs to improve.

I was trying to raise other valid points of comparison, not merely "I
don't like this about Subversion". That comparison webpage had a
strong feel of the old CUPS documentation, a sense of "you should be
only asking these particular questions", with a real lack of "what
questions do people actually ask".

That is actually one of the superior points about Subversion. The
documentation is *good*, and the "Red Bean" documentation in fact
answers all the Frequently Asked Questions. And tools like TortoiseSVN
make it *much* simpler to use than the variety of less successful and
less stable tools for graphical administration of Git.

> As Branko already said, work is being done for this, as we speak. So if
> you're interested and want to share your ideas about how this should work in
> Subversion, hop over to dev@ and give your thoughts. There are some google
> docs written by Julian Foad with design ideas, UI proposal etc, for
> 'shelving' and 'checkpointing' (which may be a first step towards local
> commits). Just search the dev@ archives for the last couple of weeks ...
> input welcome.

I can glance at it if I can find some cycles, no promises. I'm leery:
much of Subversion's support that I've seen, and that I've sold
Subversion migration work with myself, is that the singular repository
can be used to force developers to commit their work daily, to gather
some idea if they're actually working on their projects, and avoid
them squirreling away their work without code review or consistency
checks against the main development branch. Been there, done that with
personnel keeping git branches on their personal laptops or personal
VM's and being horrified with later merges or even with what I found
out they were doing later. It's enormous fun when an employee says
"I've already done that" but somehow has never published their code
anywhere that other people can see the work.

Frankly, there's already a workaround for doing local commits in
common use. It's the "git-svn" toolkit. It's far from perfect, the
handling of various "auto-fill" attributes, for example, is not
reliable. But it's proven very useful for doing local commits for
configuration management systems in testing environments, and for
folks doing Subversion->Git migrations. And where I can, I try to
forbid or discourage the use of the various autofill attributes
because they mean that what one developer has in their working copy
does not necessarily what another developer has in theirs.

I even publish RPM building wrappers for git-svn, for folks in the RPM
based operating system world. It's proven useful, though it can lead
to exactly the "you've not committed your code to the master repo!"
problems of all git projects.

Re: svn vs. git

[Paul Hammant <pa...@hammant.org>]

>
>
>
> As Branko already said, work is being done for this, as we speak. So if
> you're interested and want to share your ideas about how this should work
> in Subversion, hop over to dev@ and give your thoughts. There are some
> google docs written by Julian Foad with design ideas, UI proposal etc, for
> 'shelving' and 'checkpointing' (which may be a first step towards local
> commits). Just search the dev@ archives for the last couple of weeks ...
> input welcome.
>
>
Google's Perforce usage (before "Piper") is relevant.  Why? Because back in
2000, Perforce was one of the VCS techs that Subversion sought to ape the
features of.

Perforce in 2006, didn't have local branching or a code review mechanism.
Google, centrally, rolled out "Mondrian" in order to do code reviews.
Effectively that system, at the moment the code review was sought, would
reach into your dev workstation and pluck out a tar.gz of the change-set to
a central system. Once there code review could begin.

This 2006 video shows that UI - https://www.youtube.com/watch?v=CKjRt48rZGk.
This would ultimately act as a gate. Specifically, developers would have to
pass code review before doing 'p4 submit' to push changes back to trunk
(Google do Trunk-Based Development).  Perforce like Subversion *does not*
have a push-pull bottleneck (Git and Mercurial do) so the rate at which a
large team can submit/commit/push onto HEAD can be one a second (ore maybe
more).

In 2007 some Googlers started working on a Git local-branch capability for
their Perforce capability. It'd still be Trunk-Based Development for the
stuff that colleagues would see, but Googlers could have local private
branches. They could flip between a feature request and a bug fix casually
using Git as it was at the time. They could still enter code review - even
for two or more alternate commits to HEAD of trunk. A decent subset of the
staff used it, and were happy.  Later Git gained a Perforce integration for
everyone else to use.

What Googlers didn't do (as far as I can recall - I left in Jan 2009) was
push those multiple local branch to a remote branch for others to depend
on. At least, not with Perforce being part of that.  Now, the same
alternate change-sets being reviewed in Mondrian could be brought down to a
another developers workstation (to be improved, fixed, taken over), but
that wasn't a branch in Perforce - not remote and not local. Google's
tooling around Perforce was to augment their love of Trunk-Based
Development, their wish to have all* source in a monorepo, and to have
Build etc tooling that could casually reach any corner of that gigantic
source tree (9 million files at HEAD revision by 2015).

TL;DR. Code review is the gaping hole in Subversion.  Subversion has had
perfectly functional local branches for seven years with Git-Svn.

- Paul

* not quite all source, Android is elsewhere. Back then Wave too.

Re: svn vs. git

[Johan Corveleyn <jc...@gmail.com>]

Op 22 jul. 2017 03:00 schreef "Nico Kadel-Garcia" <nk...@gmail.com>:

On Thu, Jul 20, 2017 at 5:38 PM, Nathan Hartman
<ha...@gmail.com> wrote:
> On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jc...@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.

Sadly, it's not a balanced analysis. It's a "why all the news about
Donald Trump is faked by the liberla media, according to Fox News"
sort of analysis.


I disagree. I rather find the gazillion other comparisons that promote git
out there falling into this category. I think this is a welcome change of
perspective. But anyway, let he who is without bias cast the first stone ...


Balancing information would include "Can Subversion or git delete
dangerously or accidentally committed bulky or security sensitive
content from the repository?" This is the longest requested feature of
Subversion, and there remains no sign of it eve rhappening. If you've
ever accidentally committed a file with customer passwords, or a bulky
.iso image or core file to a working repository and seen your central
repository grow by half a Gigabyte in a single automated commit,
you'll know *exactly* what I mean. And even if committed to a branch,
it's very difficult to clear from Subversion, and *far* simpler to
clear entirely from a git repository.


Yeah, well, we know the lack of 'obliterate' is one of your favourite
complaints about svn. I am not bothered by it at all, and so are many other
svn users. But okay.

You do realise git repositories get cloned, right? So once your password
file or iso gets pulled / pushed it will be very hard to obliterate ...
It's distributed VC after all, so you have a lot more repositories to worry
about than just one.


> 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.

Or they are actually looking at problems that are not the ones listed
on that webpage. The need for constant network access to the
Subversion master for making branches and changes, for example, makes
a continuous integration and continuous development entirely dependent
on that single component. Local testing branches cannot be stored
locally with change history.


Okay, your other criticism is lack of local commits, which was also made by
some other people in this thread, and that's certainly an area where svn
needs to improve.

As Branko already said, work is being done for this, as we speak. So if
you're interested and want to share your ideas about how this should work
in Subversion, hop over to dev@ and give your thoughts. There are some
google docs written by Julian Foad with design ideas, UI proposal etc, for
'shelving' and 'checkpointing' (which may be a first step towards local
commits). Just search the dev@ archives for the last couple of weeks ...
input welcome.

-- 
Johan

Re: svn vs. git

[Nico Kadel-Garcia <nk...@gmail.com>]

On Thu, Jul 20, 2017 at 5:38 PM, Nathan Hartman
<ha...@gmail.com> wrote:
> On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jc...@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.

Sadly, it's not a balanced analysis. It's a "why all the news about
Donald Trump is faked by the liberla media, according to Fox News"
sort of analysis.

Balancing information would include "Can Subversion or git delete
dangerously or accidentally committed bulky or security sensitive
content from the repository?" This is the longest requested feature of
Subversion, and there remains no sign of it eve rhappening. If you've
ever accidentally committed a file with customer passwords, or a bulky
.iso image or core file to a working repository and seen your central
repository grow by half a Gigabyte in a single automated commit,
you'll know *exactly* what I mean. And even if committed to a branch,
it's very difficult to clear from Subversion, and *far* simpler to
clear entirely from a git repository.

> 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.

Or they are actually looking at problems that are not the ones listed
on that webpage. The need for constant network access to the
Subversion master for making branches and changes, for example, makes
a continuous integration and continuous development entirely dependent
on that single component. Local testing branches cannot be stored
locally with change history.

> 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.

Me, too. It has its uses, and tools like TortoiseSVN make it *much*
easier to use for my Windows clients.

> 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.

And saying "git does not support this" is misleading itself. Large
*binary* repositories are problem: Subversion users can, and do, check
out single directories much more efficiently.

> 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

If you're in the git world, then lean to use "tags'. Same in Subversion.

> tremendous problems we had in our pre-Subversion days have disappeared.
> Losing immutable history would be a huge step backwards for us.

In my opinion, and it's one with decades of source control experience:
Immutable history is not, per se, a "software" problem. It's a
privilege problem. Who can and should be allowed to delete the
history? This is one of the points where Subversion, described as "CVS
done right", lost an important feature of CVS.

> 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.

You can't commit your changes. If you work the way I do, with storage
and testing of new configurations, the local commits are invaluable.

> 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

Absolutely. I've personally worked, for decades, in environments where
I *do not want* to allow the server to have 24x7 access to an
externally exposed web resource. Instead, with a DVCS, I can make the
changes locally, and *pull* them to the reference server or to an
intermediate server that is far less likely to create dangerous split
brain issues than the monolithic upstream repository configuration
typical to Subversion services.

> 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.

And that's where the "I can run a staged and reviewed pull request to
the upstream master repository" becomes priceless.

> 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.

It's extremely solid and stable and well supported for what it does as
a centralized source control system. I took it over CVS and at least 3
hand-invented CVS replacements written by CTO's I worked for in a
heartbeat, and have helped with numerous migrations. But let's be very
clear about what it *is* good at, and what it's not, because when we
talk with people we need to address their real issues. Not the ones
that this webpage claims are the issues.

Re: svn vs. git

[Nathan Hartman <ha...@gmail.com>]

On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jc...@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.

RE: svn vs. git

[Andreas Tscharner <An...@wenzel-metromec.ch>]

> Subject: RE: svn vs. git
> 
> It’s been awhile, but isn’t changing the commit message (after a push)
> potentially problematic in git?
> 

Depends on whether or not you have already pushed. You can do it easily in both cases, but if you have already pushed, you should not do it, otherwise you cause problems for everyone else...

The main reason we changed from SVN to git were the merge problems we've had with SVN.

Freundliche Grüsse / Best Regards

Andreas Tscharner
Entwickler / Developer

Phone: +41 81 257 07 47
E-Mail: andreas.tscharner@wenzel-metromec.ch

WENZEL Metromec AG
Rheinfelsstrasse 1
CH-7007 Chur / Switzerland
Phone: +41 81 257 07 00
www.wenzel-metromec.ch
www.wenzel-group.com





********************************************************************************
Diese Nachricht kann vertrauliche Informationen enthalten und ist ausschliesslich für die genannte Person bestimmt. Falls Sie nicht der beabsichtigte Empfänger sind, sollten Sie diese E-Mail nicht weiterleiten, kopieren oder in sonstiger Weise verwenden. Falls Sie diese E-Mail versehentlich erhalten haben, teilen Sie dies bitte umgehend dem Sender mit und löschen Sie diese Nachricht. Vielen Dank!

This message may contain confidential information and is intended only for the individual named herein. If you are not the addressee you should not distribute, copy or otherwise make use of this e-mail. If you have received this e-mail by mistake please notify the sender immediately and delete this message. Thank you!
********************************************************************************

Re: svn vs. git

[Nico Kadel-Garcia <nk...@gmail.com>]

On Tue, Jul 25, 2017 at 4:30 PM, Andrew Reedick <jr...@incomm.com> wrote:
> It’s been awhile, but isn’t changing the commit message (after a push)
> potentially problematic in git?

Yeah. It can get nasty. The "push --force" option is available, but
that's basically changing the history on what might be a central
repository, and it's the sort of operation that makes believers in
"thou shalt not touch the history" approach to source control very,
very upset. resolving discrepancies on previously synced copies of
that central repository can get nasty if you pull that sort of stunt.

The more common option is to edit the comments on the commit you *just
made locally*. It can be handy to set the date, the problem ticket
number, or to mention an additional change before making the push. And
it's especially handy to reset the "author" of a commit, because a
local commit is normally attributed to the local user on the local
host. If you're logged in as the "root" or "apache" user, to modify a
local configuration repository, it's useful to reset the "author" to
yourself before doing the push.

Resetting the "author" of a commit introduces additional dangers: for
Subversion, the "commit" is credited to the user connecting to the
Subversion server. For git, it can be reset locally, and people can
*lie* about who did the specific commit.

RE: svn vs. git

[Andrew Reedick <jr...@incomm.com>]

It’s been awhile, but isn’t changing the commit message (after a push) potentially problematic in git?

Re: svn vs. git

[Stefan Sperling <st...@apache.org>]

On Fri, Jul 21, 2017 at 11:45:05AM -0700, Xin LI wrote:
> Hi, Stefan,
> 
> Thanks for your feedback!  Please see my response inline.
> 
> On Fri, Jul 21, 2017 at 2:16 AM, Stefan Sperling <st...@apache.org> wrote:
> > On Thu, Jul 20, 2017 at 08:01:55PM -0700, Xin LI wrote:
> > The FreeBSD repository is one of the best real world data sets available
> > to Subversion developers. I have referred to it several times while
> > working on the new conflict resolver planned for Subversion 1.10 and
> > have spent days running test merges against this repository.
> > The repository shows many difficult and interesting problems we would
> > normally only see in repositories that are locked up inside companies.
> >
> > While some of the problems I have seen are due to limitations of SVN,
> > I believe most problems FreeBSD developers have with SVN are self-made.
> > FreeBSD developers in general do not really understand the tool and
> > don't know how to work arounds its weaknesses. The FreeBSD handbook has
> > a section on Subversion which is full of bad advice and half-truths.
> 
> I guess you mean this article?
> https://www.freebsd.org/doc/en/articles/committers-guide/subversion-primer.html

Yes.

> Could you please be more specific with the bad advices?  (It would be
> very helpful if we could have fixed these documents and/or practices,
> if possible; I'll take a look at the premier to get the issues raised
> in EuroBSDCon 2014 tutorial addressed).
 
Sure. I'll go through it and point out things that stand out very positively
or negatively. Some information contained in this guide is simply outdated.

"5.3.2. Checkout"
"Note: Decreasing the depth of a working copy is not possible."
Long outdated advice. See the --depth=exclude option introduced in 1.6 (2009).
http://subversion.apache.org/docs/release-notes/1.6.html#sparse-directory-exclusion

"5.3.7. Adding and Removing Files"
"Before adding files, get a copy of auto-props.txt"
No longer necessary since Subversion 1.8 (2013). Use svn:auto-props instead.
http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config

"5.3.10. Diffs" should probably mention the --old and --new
syntax which can be used to compare arbitrary files and directories,
local and/or in the repository, including unversioned items.
This syntax is described in 'svn help diff', but is worth pointing out
anyway. http://subversion.apache.org/docs/release-notes/1.8.html#svn-diff

"5.3.12. Conflicts"
The list of possible values for the --accept option is incomplete.
Should mention that 'svn help' always has an up-to-date list.
The prominently mentioned 'mine-full' and 'theirs-full' options are
rarely needed. Most of the time, using the 'edit' command (e) at
the conflict prompt is the best path forward. In some cases (e.g.
files which use a line-by-line syntax) the 'merge' (m) command
provides a useful merge tool inspired by OpenBSD's version of sdiff(1).
http://subversion.apache.org/docs/release-notes/1.8.html#file-merge-tool

"5.4.1. Sparse Checkouts"
List of --depth option arguments is incomplete (lacks "exclude").

"5.4.2. Direct Operation"
"Certain operations can be performed directly on the repository without touching the working copy."
"merge" <-- wrong! Merge modifies the working copy unless --dry-run is used.


"5.4.3. Merging with SVN"

"5.4.3.1. About Merge Tracking"

" When set on a file, [mergeinfo] applies only to that file. When set on
a directory, it applies to that directory and its descendants (files and
directories) except for those that have their own svn:mergeinfo."

The above is the only part of this entire section which is 100% correct.

"It is not inherited. For instance, stable/6/contrib/openpam/ does not
implicitly inherit mergeinfo from stable/6/, or stable/6/contrib/."

This claim is true only if stable/6/contrib/openpam/ has an svn:mergeinfo
of its own. Otherwise it's just wrong. The remaining explanations provided
(which I won't quote here) about how mergeinfo inheritance works are vastly
oversimplified and can lead to misunderstandings and false conclusions.
I would delete them and instead refer interested readers to these articles
by Paul Burba which cover the subject in depth:
https://www.open.collab.net/community/subversion/articles/merge-info.html
http://blogs.collab.net/subversion/where-did-that-mergeinfo-come-from
(As an aside, it would be great to have some content from these articles
copied into the svnbook, provided Paul grants permission).


"5.4.3.3. Selecting the Source and Target for stable/10 and Newer"

"all merges are merged to and committed from the root of the branch"

Good!

However, this guide should also encourage (local) experimentation with
various merge tricks between paths when it comes to resolving tree conflicts.

While it often helps to think of directories in the repository as entire
branches when starting a merge, it can also help to think of a Subversion
repository as what it really is: a collection of revisions and paths with
ancestral relationships modelled via copies. When resolving tree conflicts,
this is right level of abstraction to use.


"5.4.3.4. Selecting the Source and Target for stable/9 and Older"
"For stable/9 and earlier, a different strategy was used, distributing mergeinfo around the tree so that merges could be performed without a complete checkout. This procedure proved extremely error-prone, with the convenience of partial checkouts for merges significantly outweighed by the complexity of picking mergeinfo targets. The procedure below describes this now-obsoleted process, "

No kidding! I'll just say that I'm happy this process was already changed.

"Never merge directly to a file.
Never, ever merge directly to a file.
Never, ever, ever merge directly to a file."

This was apparently written by someone who got burned by merge-tracking bugs
and lack of good tree conflict handling, didn't ask experts for help, and
resorted to just warning everyone to stay away from ever trying.
I have to admit that I have found myself having that same attitude towards
functions of tools I have had to use and probably didn't understand well :)

The correct answer is: It depends. As shown in my EuroBSDcon 2014 tutorial,
it may make sense to merge directly between files if resolving tree conflicts.


"5.4.3.5. Preparing the Merge Target"

"it is very important to never merge changes into a sparse working copy"

Yes! Read Paul Burba's articles to see why.


"5.4.3.9. Committing"

"Make sure to commit a top level directory to have the mergeinfo included
as well"

Good and essential advice.


"5.4.4.1.1. Flattening"
"The propdel bit is necessary because starting with 1.5, Subversion
will automatically add svn:mergeinfo to any directory that is copied or moved."

No longer true. Working-copy -> working-copy copies do not create mergeinfo.

"5.4.4.2.2. Importing into the Vendor Tree"

"the svn add and svn rm commands are used as needed:"

It makes sense to use 'svn move' instead of 'svn rm' followed by 'svn add'
where the vendor has moved files. This will become useful with Subversion 1.10.

"5.4.4.3. Merging to Head"

"^ is an alias for the repository path."

It's ^/, not just ^.

Why is the ^/ URL shortcut not mentioned more prominently much earlier,
e.g. in sections 5.4.2 or 5.4.2?


"5.4.6. Fixing Mistakes"

There is not such thing as the "repository journal" mentioned here.
I would suggest to replace "repository journal" with "repository".


"5.5. Some Tips"

"It is possible to automatically fill the "Sponsored by" and "MFC after" commit
log fields by setting "freebsd-sponsored-by" and "freebsd-mfc-after" fields in
the "[miscellany]" section of the ~/.subversion/config configuration file. For
example:
freebsd-sponsored-by = The FreeBSD Foundation
freebsd-mfc-after = 2 weeks"

I wish FreeBSD was putting some effort into getting their custom
features integrated in stock Subversion.

We managed to get FreeBSD's custom keywords patch integrated in 1.8.
http://subversion.apache.org/docs/release-notes/1.8.html#custom-keywords
Where is the rest? See http://subversion.apache.org/contributing.html#code

> > At EuroBSDcon 2014 I offered a special SVN tutorial for FreeBSD developers.
> > There were many participants but *nobody* of them were FreeBSD developers :(
> > There was a clear lack of interest for this kind of communication.
> > So the tutorial didn't go as planned and no interesting conversation happened.
> > You can still find the tutorial here (one of your own bad merges was discussed
> > in there, too, I believe): https://stsp.name/eurobsdcon2014-freebsd/
> 
> I didn't knew this tutorial before, and thanks for taking time to do
> the analysis and sharing.
> 
> So if I understood correctly, when doing a vendor import with file
> renames, in addition of doing 'svn mv's in the vendor tree [quick
> question: is there some semi-automated way to do this?], the developer
> should also handle the merge conflicts differently in the development
> trunk, by replaying each merges with:
> 
> svn revert <old file>        # Restore the file to before merge state
> svn rm <new file>           # Remove new file in preparation of actual merge
> svn mv <old file> <new file> # Move old file to new location
> svn merge --accept postpone ^/vendor/.../<old file>@<vendor commit -1>
> ^/vendor/.../<new file>@<vendor commit> <new file>
> 
> Then do a 'svn propdel svn:mergeinfo' on these new files?
> 
> [Do we need to do similar changes when merging to stable/?]

Perhaps. I have looked at specific examples. I don't know how widely
any of them can be generalized. A competent developer should be able
to decide that for themselves.

My goal when writing the tutorial was to encourage experimentation with
solutions that go beyond just running "svn merge" and hoping for the best.
This requires some understanding of Subversion beyond what the FreeBSD
handbook can provide. But given the high standards FreeBSD sets for its
developers in other matters, I don't see why that should be a problem.

> And am I understanding correctly that the benefit of doing this is
> that the new files now get the same change history line from
> development trunk, instead of as a continue of the vendor history, and
> also avoided missing changes that happen in development trunk but not
> in vendor area (or development trunk)?

Yes, it seems more natural to me to have linear history on trunk.
Only people doing vendor imports should have to deal with their vendor branch.
Other people should never see their 'svn log' output go there.

One problem with my solution is that a merge like this indeed needs to
be scripted. Because Subversion is unable to match up the paths by itself
a lot of commands need to be run. This is unfortunate, but will improve
over time, with Subversion 1.10 being another huge step forward.

However, I do think that using some scripting to perform complex merges
is a healthy attitude and a nice tool developers should be using. If a merge
doesn't work automatically, try to script the merge so it runs automatically
starting from a clean working copy. Some trial and error should find the best
path forward in the given situation. Once you're happy, run the final script
once more with an "svn commit" command appended at the end.

A 1.10.0-alpha3 release will be out soon. I'd encourage you to try my
tutorial with this version, and let us know what you think.

Cheers,
Stefan

Re: svn vs. git

[Xin LI <de...@gmail.com>]

Hi, Stefan,

Thanks for your feedback!  Please see my response inline.

On Fri, Jul 21, 2017 at 2:16 AM, Stefan Sperling <st...@apache.org> wrote:
> On Thu, Jul 20, 2017 at 08:01:55PM -0700, Xin LI wrote:
> The FreeBSD repository is one of the best real world data sets available
> to Subversion developers. I have referred to it several times while
> working on the new conflict resolver planned for Subversion 1.10 and
> have spent days running test merges against this repository.
> The repository shows many difficult and interesting problems we would
> normally only see in repositories that are locked up inside companies.
>
> While some of the problems I have seen are due to limitations of SVN,
> I believe most problems FreeBSD developers have with SVN are self-made.
> FreeBSD developers in general do not really understand the tool and
> don't know how to work arounds its weaknesses. The FreeBSD handbook has
> a section on Subversion which is full of bad advice and half-truths.

I guess you mean this article?
https://www.freebsd.org/doc/en/articles/committers-guide/subversion-primer.html

Could you please be more specific with the bad advices?  (It would be
very helpful if we could have fixed these documents and/or practices,
if possible; I'll take a look at the premier to get the issues raised
in EuroBSDCon 2014 tutorial addressed).

> I wish there was more communication between the FreeBSD and Subversion
> projects about such issues, but such communication is virtually never
> existed. (I may be wrong, but I think you are the only FreeBSD developer
> posting on this list -- thank you!)

I think there are other FreeBSD developers on this mailing list.

> At EuroBSDcon 2014 I offered a special SVN tutorial for FreeBSD developers.
> There were many participants but *nobody* of them were FreeBSD developers :(
> There was a clear lack of interest for this kind of communication.
> So the tutorial didn't go as planned and no interesting conversation happened.
> You can still find the tutorial here (one of your own bad merges was discussed
> in there, too, I believe): https://stsp.name/eurobsdcon2014-freebsd/

I didn't knew this tutorial before, and thanks for taking time to do
the analysis and sharing.

So if I understood correctly, when doing a vendor import with file
renames, in addition of doing 'svn mv's in the vendor tree [quick
question: is there some semi-automated way to do this?], the developer
should also handle the merge conflicts differently in the development
trunk, by replaying each merges with:

svn revert <old file>        # Restore the file to before merge state
svn rm <new file>           # Remove new file in preparation of actual merge
svn mv <old file> <new file> # Move old file to new location
svn merge --accept postpone ^/vendor/.../<old file>@<vendor commit -1>
^/vendor/.../<new file>@<vendor commit> <new file>

Then do a 'svn propdel svn:mergeinfo' on these new files?

[Do we need to do similar changes when merging to stable/?]

And am I understanding correctly that the benefit of doing this is
that the new files now get the same change history line from
development trunk, instead of as a continue of the vendor history, and
also avoided missing changes that happen in development trunk but not
in vendor area (or development trunk)?

Thanks in advance!

Cheers,

Re: svn vs. git

[Stefan Sperling <st...@apache.org>]

On Thu, Jul 20, 2017 at 08:01:55PM -0700, Xin LI wrote:
> 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'.

The FreeBSD repository is one of the best real world data sets available
to Subversion developers. I have referred to it several times while
working on the new conflict resolver planned for Subversion 1.10 and
have spent days running test merges against this repository.
The repository shows many difficult and interesting problems we would
normally only see in repositories that are locked up inside companies.

While some of the problems I have seen are due to limitations of SVN,
I believe most problems FreeBSD developers have with SVN are self-made.
FreeBSD developers in general do not really understand the tool and
don't know how to work arounds its weaknesses. The FreeBSD handbook has
a section on Subversion which is full of bad advice and half-truths.

I wish there was more communication between the FreeBSD and Subversion
projects about such issues, but such communication is virtually never
existed. (I may be wrong, but I think you are the only FreeBSD developer
posting on this list -- thank you!)

At EuroBSDcon 2014 I offered a special SVN tutorial for FreeBSD developers.
There were many participants but *nobody* of them were FreeBSD developers :(
There was a clear lack of interest for this kind of communication.
So the tutorial didn't go as planned and no interesting conversation happened.
You can still find the tutorial here (one of your own bad merges was discussed
in there, too, I believe): https://stsp.name/eurobsdcon2014-freebsd/

Re: svn vs. git

[Xin LI <de...@gmail.com>]

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 <jc...@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)
>
> --
> Johan