Re: Moving pkgsrc-wip away from SourceForge

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On 14 July 2015 at 12:40, D'Arcy J.M. Cain <darcy%netbsd.org@localhost> wrote:
> On Tue, 14 Jul 2015 12:18:26 -0400
> Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
>> Subversion? Please, no.
>>
>> While chewing on razer blades is probably a safer and more pleasant
>> experience than GIT, subversion still manages to be worse.
>
> Hyperbole aside...
>
>> I've, on multiple occasions found my day job being spent trying to
>> disentangle the mess the developers made of their SVN repository.
>> Specifically:
>>
>> - SVN is not atomic; the sequence "pull ; edit ; build ; push" offers
>> no guarantee that the tree is left in a buildable state.
>> While other DVCS will reject the push if the repo has changed, SVN
>> does not - this is by design
>
> Not true.  If I try to commit a change and the file on the repo has
> changed it won't let me.  It may be that other files in the repo have
> changed but if I had to make sure that every file in my copy was up to
> date before committing I could have a real problem on a large system
> with lots of developers working on different parts of the tree.

Two data points:

- I prefer to know about interface changes that my break my build,
before I do the push
- it turned out that I wasn't alone, the incident of broken builds
dropped measurably after a switch away from SVN - it was no longer
possible to blame someone else

I guess we agree to disagree on what 'atomic' means and how important it is.

>> - SVN is for ever trying to phone home
>> The D in DVCS is Distributed.  You shouldn't need to be connected to
>> do work.
>
> For some use cases.  It's not a universal requirement.
>
>> - SVN has no real underlying branch/tag framework behind it; instead
>> there is just free form directory naming conventions
>> Like any good convention, there's more than one to choose from; and
>> projects do just that.  This really comes to a head when you try to
>> migrate out any sort of history out of SVN and back into something
>> even vaguely sane.
>
> There are best practices that work just fine.  I am sure that someone
> blindly using the tool without doing any research can mess things up
> but that's probably true of any tool.

A valid criticism of GIT is that, like razer blades, there's too much
opportunity to cut one's fingers.  Yet here we've got an argument that
it is perfectly legitimate for SVN to hand out razer blades.

The SVN repo designs I encountered were reasonable.  It just turns out
that, unless you actually try to migrate away from SVN (to GIT or HG
or ..) you won't know how practical it actually is.  I don't think it
is reasonable to blame the original designers, who assumed SVN was
forever, for missing that.

>> - As a corollary of the above, SVN lets you change everything, at once
>> While CVS, GIT, et.al. all have the convention of: checkout a branch;
>> change branch; commit/push/...; SVN (the tool), for what ever reason,
>> seems to encourage developers to checkout a single copy of the entire
>> tree (branches, tags, and all) and then just hack stuff randomly.
>
> Have you used SVN?  I check out subsets of the repo all the time.  I
> can also check out a specific branch and work on that.  In fact, I have
> heard git users complain about the fact that it *doesn't* check out the
> entire tree.  It only checks out the branch (usually HEAD) that is
> being requested.

i did mention what I was doing.  Perhaps I should mention why.  While
new team members were increasingly familiar with GIT and equally
frustrated with SVN (to the point that they were trying to use GIT as
an SVN front-end), the final nail in SVN's coffin came when Atlassian'
decided to pretty much drop SVN support.

So, go ahead, adopt SVN.

Andrew