Subject: [Tools-discuss] svn vs. git

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 11 Jun 2014 07:10:21 +0000

Hi,

ever since I started to use git, I grow more dissatisfied with svn.

The pain of merging 5.5.0 into my local - heavily modified - development branch is just adding to that frustration.

Would it be possible to set up some sort of svn-to-git thing to access the tools svn repos? Would http://git-scm.com/docs/git-svn work?

Lars

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 11 Jun 2014 09:38:05 -0400

> Would it be possible to set up some sort of svn-to-git thing to access the tools svn repos? Would http://git-scm.com/docs/git-svn work?

git-svn has its quirks, but i find it to be the best svn client around
:)  But i think there's no need for it to be done centrally, if the
folks maintaining the tools prefer to work with an svn repository.  Each
client can maintain their own git-svn working repo, and can use all the
git merge/rebase/etc tools they've grown accustomed to, just doing a
"git svn fetch" or "git svn rebase" to keep up-to-date with the mainline
of development.

If you have write access to svn, you can use "git svn dcommit" to push
your local changes into svn changes and keep your working repo aligned
to it.

hth,

	--dkg

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 11 Jun 2014 13:55:41 +0000

> your local changes into svn changes and keep your working repo aligned

Thanks for the explanation!

Do I get git's superior merging capabilities if I run git-svn against an upstream svn? (I have a development branch where many files are renamed and moved around versus upstream, and svn fails miserably in tracking the changes. (It doesn't even flag them as merge conflicts.)

Lars

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 11 Jun 2014 16:31:17 +0200

Hi Lars,

> Would it be possible to set up some sort of svn-to-git thing to access the tools svn repos? Would http://git-scm.com/docs/git-svn work?

We've had one contractor that worked through a svn-to-git thing, and it was an
absolute royal pain to merge his code to trunk, possibly because merge history
and information is lost in the translation.  The merges simply went wrong, old
changes were reverted, and it was a mess.

My experience with SVN merges these days is that I only get asked about conflicts
when there are changes to the same code lines in the two branches, and that needs
eyeballs in any case ...

Could you say something more about the pain you experienced?  Also, I assume you
have been merging your branch forward to new copies of trunk gradually -- was
this also a merge of your branch to a new copy of trunk, or was it exactly what
you say above, merging trunk to your branch?  I'd expect the latter to be messy
if you've earlier merged your branch to new copies of trunk ...

Best regards,

	Henrik

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 11 Jun 2014 11:02:23 -0400

On 06/11/2014 09:55 AM, Eggert, Lars wrote:
> Do I get git's superior merging capabilities if I run git-svn against an upstream svn?

Yes, you do.  I find it helps to think of upstream's svn as an
independent git repo that i'm just tracking, against which i often merge
or rebase.

> (I have a development branch where many files are renamed and moved around versus upstream, and svn fails miserably in tracking the changes. (It doesn't even flag them as merge conflicts.)

I think i have experience with large numbers of changes at that level,
so i can't make any promises :)  I recommend giving it a try and seeing
what happens.  I don't know how you're tracking your current changes --
are they just kept in your svn working directory, or do you have some
other history?

when committing a branch of changes back to svn (if it comes to that), i
recommend always rebasing it to the current svn head, rather than trying
to do a merge in both git and svn.

If you have no revision history of your current changes, just a big
outstanding patchset, I think your work to set this up would be:

 * git init and git fetch into a new local repository, entirely from
upstream

 * make a new git branch for your development work

 * transfer your local changes into the local repository (e.g. by
recursively removing everything but .git/ and copying everything else
back over from your actual live code

 * commit the changes git reports, either in a lump (not ideal), or as
logically distinct changesets (better).

 * when changes happen upstream, you'd want to do "git svn fetch" or
"git svn rebase" or "git rebase" for the branch you're working on.

Also, if the changes you've got are sensible changes for upstream,
please send the diffs (rebased off of the current svn trunk, where
possible) to the mailing list, so you can minimize your divergence from
upstream!

hth,

	--dkg

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jun 2014 11:17:31 -0500

> ever since I started to use git, I grow more dissatisfied with svn.

+1

> Would it be possible to set up some sort of svn-to-git thing to access the tools svn repos? Would http://git-scm.com/docs/git-svn work?

The MIT Kerberos team used to use CVS, then moved to SVN, then setup
an SVN->git gateway and setup to accept PRs on github, finally they
moved to git.  So, yes, an SVN<->git gateway can be setup.  I don't
know how much pain that entails -- it might be very little.

In any case, SVN is the stone ages by comparison to git.  For a large
diffuse team of collaborators git is superior to the rest.  The
ability to keep local changes on top with ease (rebase) is a godsend:
it pushes merge pain to the contributor, making merges much easier for
the upstream, and it makes merges easier on the contributor too
(because fewer in each case of conflicts it will be clearer where they
are coming from).

The least we could do is stop the use of SVN for new things.  Setting
up SVN->git gateways would be lovely.  Moving to git would be nicer.

Note that moving to git does not mean abandoning the current issues
system, only setting up new hooks.

Nico
--

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jun 2014 09:54:04 -0700

> system, only setting up new hooks.

I'll note that several working groups that I'm involved with have
started that move.  Our experience with HTTP/2 has been nothing but
positive.

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Jun 2014 12:02:56 -0500

> started that move.  Our experience with HTTP/2 has been nothing but

The sooner we bite this bullet, the better.

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 12 Jun 2014 07:44:22 -0400

> started that move.  Our experience with HTTP/2 has been nothing but

I've been experimenting with this in DNSOP with certain documents, and 
it's helped kick start some of the authors to collaborate a bit more.

tim

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Jun 2014 15:04:17 +0200

Hi Tim,

Adding Cc: Julian, for possible feedback.

> it's helped kick start some of the authors to collaborate a bit more.

To my mind, there seems to be a few different features that attract people
to git, and understanding which of those is the essential one in various
use cases would be helpful in determining what could be offered on tools.ietf.org

 - There are people who prefer git because of its merge capabilities, in
   particular its ability to handle files which have changed location
   within the repository.

 - There are people who prefer git because of its distributed nature, which
   for example makes it possible for any number of contributors to contribute
   patches to the linux kernel without any central repository management or
   access control management.

 - There are people who prefer git because they have become accustomed to
   it, and can't be bothered to do things in a different manner.

 - There are people who prefer _github_ because of the ease with which you
   can grab a copy of a repository, fiddle with it, and then request a pull
   back to the master (providing both repos are on github).  Please note
   that this (the pull-request integration) is a feature of github, rather
   than git itself.

Now, I would be happy to understand which of these (or other unlisted features)
are the main reason why for instance httpbis and dnsop are happy with the move.
Most times when I've tried to drill down to understand this, it seems that it's
not really _git_ which provides the added ease of use, it's the additional
features of _github_ that provides that.

If this is the case, then rolling out git as an alternative to svn on tools.ietf.org
would most likely be a non-starter, unless it was possible to also provide the
features which make _github_ attractive.

Information please?

Best regards,

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Jun 2014 15:15:39 +0200

> features which make _github_ attractive.

gitlab (6.x) has merge requests (what github calls pull requests).
(I must admit I have more experience with github-the-site than with gitlab-the-tool.
But students here seem to like our local gitlab installation for study-related repos.)

Both github and gitlab are somewhat limited in their commenting features; I hope we can get some tool support here eventually based on what the more Web-affine WGs have been doing.

And yes, the other major point is that git allows you to work locally, with a sequence of multiple commits, before doing a cleanup “git rebase -i” and “git svn dcommit”ing (or “git push"ing in the future).

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 15:28:19 +0200

>     particular its ability to handle files which have changed location

I thought SVN does this as well.

> are the main reason why for instance httpbis and dnsop are happy with the move.

Actually, I'm not happy with the move at all. Which of course is partly 
because I'm using svn for almost everything else, and still struggle to 
adjust my mental model.

I agree that github's issue tracker looks slightly cooler than the Trac 
we use on tools.ietf.org.

> features of _github_ that provides that.

Likely.

> features which make _github_ attractive.

Best regards, Julian

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 12 Jun 2014 09:57:30 -0400

Henrik

Also, DNSOP is/was/maybe going to be working on a few documents with 
folks outside of IETF (i.e., ICANN).  I wanted to use something more 
'neutral' to encourage collaboration.   But I found the git issue 
tracker a  simpler workflow for tracking document changes. Also, the 
'gist' features allows for short chunks of code (or text) that can be 
looked at usually quicker, and then approved/rejected/etc.

I've used github, gitlabs, and the Atlassian commercial version (Stash), 
and they all have pros and cons.

I currently use svn and git in my day job, and its different approaches 
to the problem.

I would say there has been some discussion (as least among the ops 
chairs) on the relevance of IETF compared to open source, and my thought 
was that a way to give the appearance of being more open/inviting/etc is 
to use the current standard bearer of open source folks.

tim

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Jun 2014 07:05:06 -0700

>   that this (the pull-request integration) is a feature of github, rather

Excellent, list, Henrik. That is what I hear as well.

Not on the list, however, is why many people who are familiar with both git and svn prefer svn. Speaking for myself:

- The commands for svn, while sometimes frustrating, are much more understandable than those for git.

- When one of the tools goes wonky (such as when you rename something using a non-git or non-svn command), recovering from svn is more reliable than recovering from git.

- The GUI front ends for svn on the Mac feel more intuitive to my workflow than the GUI front ends for Git.

- The GitHub methodology for fork-edit-pullrequest is burdensome for commenters who just want you to fix this one thing.

I believe that the people who like git and/or GitHub have good reasons to do so, and their thinking aligns well with their tool of choice. But those of us who have looked at both and are staying with the no-longer-cool svn for our day-to-day work have good reasons as well. I will probably end up moving to git, but would like to delay doing so until there has been more work done on making git more useful to the casual user.

--Paul Hoffman

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Jun 2014 16:22:06 +0200

Hi Carsten,

>> features which make _github_ attractive.

Ok.

> gitlab (6.x) has merge requests (what github calls pull requests). (I
> must admit I have more experience with github-the-site than with
> gitlab-the-tool. But students here seem to like our local gitlab
> installation for study-related repos.)

Ok.

> Both github and gitlab are somewhat limited in their commenting
> features; I hope we can get some tool support here eventually based
> on what the more Web-affine WGs have been doing.

Ok.

> And yes, the other major point is that git allows you to work
> locally, with a sequence of multiple commits, before doing a cleanup
> “git rebase -i” and “git svn dcommit”ing (or “git push"ing in the
> future).

Ok.  Thank you!

Best regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Jun 2014 16:22:25 +0200

Hi Julian,

> I thought SVN does this as well.

Not as well as git, because of the way git uses hashes to identify files, no
matter what they are called and where they are placed.  I think Lars' latest
merge, in particular, where a whole bunch of filed had been moved from one
directory to another, as part of a generalization and cleanup, would have
been handled better by git.

> because I'm using svn for almost everything else, and still struggle to 

Ok, and ack.

> we use on tools.ietf.org.

Ok :-)

>> features of _github_ that provides that.

Ok, and thanks.

Best regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Jun 2014 16:35:20 +0200

Hi Tim,

> looked at usually quicker, and then approved/rejected/etc.

Interesting.  I'll look.

> I currently use svn and git in my day job, and its different approaches 

Ack.  I also use both, and I agree with that.

> to use the current standard bearer of open source folks.

Mph.  I've been an open-source adherent and proponent for 20 years or more
(I think my first contribution was code which added support for Ungerman-Bass
networks to Kermit in 1988) and I consider svn just as much open-source as
git.  Supporting git for _this_ reason instead of doing it because it was
the right technical solution for a task might just as likely end up tarnishing
the IETF's reputation for caring about good technical solutions.

Best regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Jun 2014 16:46:47 +0200

Hi Paul,

On 2014-06-12 16:05 Paul Hoffman said:
> I believe that the people who like git and/or GitHub have good
> reasons to do so, and their thinking aligns well with their tool of
> choice. But those of us who have looked at both and are staying with
> the no-longer-cool svn for our day-to-day work have good reasons as
> well. I will probably end up moving to git, but would like to delay
> doing so until there has been more work done on making git more
> useful to the casual user.

I agree with this list, except that it's extremely seldom that I use GUI front-
ends, so have no opinion on those.  How well one likes the command-set is probably
both a personal thing and a matter of habit, of course.

For me, there's one additional point which is important in some use cases:

 - If you are working with a contractor producing code for a specified project,
   the ability to follow each commit to a central repository makes it possible
   to catch misunderstandings about the project specification much earlier than
   if the contractor was doing commits to a local repository for quite a spell,
   only providing intermediate releases.  With contractors working for the IETF,
   this has in several cases been very important in order to steer things right
   as early as possible.  Here svn shines in comparison with git, exactly because
   it doesn't let you commit locally.

Best regards,

	Henrik

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 12 Jun 2014 10:48:34 -0400

>    that this (the pull-request integration) is a feature of github, rather

Thanks for this list, Henrik, and for being open to the discussion.  I
know changes like this can be painful, and frustrating for folks who
like the status quo, but i think they're worth having.

Fwiw, i prefer git for the first two reasons you mention, as well as for
the fact that i think having a copy of the full repository on every
developer's workstation is a decent hedge against centralized breakage
(whether accidental or as the result of a compromise).  Git's
decentralized nature doesn't mean you *can't* have a central or
canonical repository, but it makes it clear that all the rest of the
repos are as capable and complete as the canonical one.

And i prefer not to use github.  I can (and do) use github where
upstream projects have made it a requirement for their workflow, but i
would much rather interact with patches through my MUA (which has
reasonable and bounded semantics, avoids promiscuous remote code
execution, and has sensible offline modes) than with my web browser.
Sending patches through the mailing list also means we have an archive
of what changes were proposed and who made them, should it come to that.

I also don't like the idea that critical ietf infrastructure would be
hosted on machines that aren't in the IETF's bailiwick.

My preference would be to move to git and have patches continue to be
sent to the mailing list or posted to the IETF trac instance.  I can
give pointers on integrating trac and git, if that would be helpful.

Regards,

	--dkg

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Jun 2014 16:52:11 +0200

On 12 Jun 2014, at 16:05, Paul Hoffman <[email-masked]> wrote:

> intuitive

In usability, “intuitive” is a synonym for “familiar”.
The fact that subversion has been around for longer than git and there are lots of people more used to that will always add noise to a discussion about the relative merits.

People who are moving a lot of code are more likely to have made the (painful) jump to git by now.
Even if there are good reasons for staying with SVN for a specific project, “still using SVN” has a strong connotation of cluelessness (or, worse, being helplessly stuck in PHB-land) to many of us.

Casual contributors are probably better off with a Web-based commenting feature anyway.
(And gists do help; good point Tim.)

(BTW, I’m aware of only one reasonably usable GUI for git, and that is SourceTree; if you have only tried the other ones, you may be missing out.)

Oh, and Henrik, if you want to get a contractor to continually push intermediate versions to a central repo, how about asking them to do that (or even writing it into the contract)?  (I constantly have to remind students to do this, but it usually clicks within a day or two.)

Grüße, Carsten

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 12 Jun 2014 10:52:49 -0400

>    it doesn't let you commit locally.

This seems like a contractual arrangement that could be stipulated: do
your development work on a branch, and push the commits on that branch
to $shared_repo at least $frequency so that it can be reviewed.

fwiw, i've had even worse experiences with third-parties and svn, where
someone "wasn't quite sure" about their work, and so didn't want to
commit it at all, and just kept it as a (huge, messy) changeset until
they were "sure", and then made one huge svn commit.  In that case, the
centralized requirement of svn actually deterred the third party from
making incremental commits at all, so there was no good way to review
the changes as they went, *and* there was no good way to review them
piecemeal even retroactively.

	--dkg

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Jun 2014 17:17:30 +0200

Hi Carsten,

On 2014-06-12 16:52 Carsten Bormann said:
> In usability, “intuitive” is a synonym for “familiar”. The fact that 
> subversion has been around for longer than git and there are lots of 
> people more used to that will always add noise to a discussion about 
> the relative merits.
> 
> People who are moving a lot of code are more likely to have made the 
> (painful) jump to git by now. Even if there are good reasons for 
> staying with SVN for a specific project, “still using SVN” has a 
> strong connotation of cluelessness (or, worse, being helplessly
> stuck in PHB-land) to many of us.
> 
> Casual contributors are probably better off with a Web-based 
> commenting feature anyway. (And gists do help; good point Tim.)
> 
> (BTW, I’m aware of only one reasonably usable GUI for git, and that 
> is SourceTree; if you have only tried the other ones, you may be 
> missing out.)
> 
> Oh, and Henrik, if you want to get a contractor to continually push 
> intermediate versions to a central repo, how about asking them to do 
> that (or even writing it into the contract)?

Tried that, in one case, but it didn't work out too well -- it would
require that *every* commit was followed by a push, which didn't happen.

> (I constantly have to remind students to do this, but it usually
> clicks within a day or two.)

The thing is, how do I know to give the contractor feedback?  I'd hate
to have to sit down every day and write a letter "haven't seen any
pushes today, did you forget?"  With some, it proves enough of a hassle
to get them to submit weekly reports -- the worst case required
reminders every other week, even when I emailed them a template
to fill in, every week :-(

I think I'm saying that I'm sure it is possible, but the cat-herding
is simply taken out of the equation if one uses a tool that doesn't
permit local commits.

Best regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Jun 2014 17:22:26 +0200

Hi Daniel,

> to $shared_repo at least $frequency so that it can be reviewed.

Yes, as I wrote to Carsten, I'm sure it's possible, it's just turned out
to be painful the times I've tried it.

> they were "sure", and then made one huge svn commit.

Right.  Great ,,:-}

But there's a different problem at the bottom of _that_, I'd say.

> In that case, the

Ugh.  Understood.  I wouldn't be particularly happy about paying a contractor
who showed that level of competence -- but on the other hand it's more likely
to happen when people start out in a field, not with vetted contractors.  Could
happen though.

Best regards,

	Henrik

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Jun 2014 08:25:35 -0700

>   it doesn't let you commit locally.

Yes, yes, yes! And I believe that Julian would agree with this one as well: he and I are using the IETF svn repo for some IETF work we are doing together, and he sometimes will respond to a minor check-in that I have done pointing out a mistake or misunderstanding. As much as I dislike that :-), it causes corrections earlier.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Jun 2014 08:33:21 -0700

> In usability, “intuitive” is a synonym for “familiar”.

Sometimes, but given that both git and svn are recent (<5 years) for me, that's not accurate in this case.

> The fact that subversion has been around for longer than git and there are lots of people more used to that will always add noise to a discussion about the relative merits.

It can, yes. But I do feel that "intuitive" actually has value in the discussion because we are talking about work *styles*, not just commands given. For some people, the style of central repo with frequent check-ins of small changes is a more intuitive style; for others, everyone having everything on their local machine and big merges is a more intuitive style. I'm in the first camp, but I don't mind working with people who are in the second camp.

> People who are moving a lot of code are more likely to have made the (painful) jump to git by now.

Yes, fully agree. I don't see the IETF document development process as being that way, and from my (mostly outside) observation, the IETF tool development process isn't that way either. However, that latter may be a side-effect of using svn.

> Even if there are good reasons for staying with SVN for a specific project, “still using SVN” has a strong connotation of cluelessness (or, worse, being helplessly stuck in PHB-land) to many of us.

That's fashion, not style.

> (And gists do help; good point Tim.)

Please say more about that; I haven't seen gists used much at all in the places I have used GitHub.

> (BTW, I’m aware of only one reasonably usable GUI for git, and that is SourceTree; if you have only tried the other ones, you may be missing out.)

I used SourceTree, and it seems primitive relative to svn GUIs like Cornerstone.

> Oh, and Henrik, if you want to get a contractor to continually push intermediate versions to a central repo, how about asking them to do that (or even writing it into the contract)?  (I constantly…

Yeah, if we go to git as the accepted repo tool, we might have to also have to emphasize that some management style is needed as well.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 Jun 2014 11:43:35 -0500

> use cases would be helpful in determining what could be offered on tools.ietf.org

My list is different than yours:

 - git is just a pile of objects forming a tree of Merkle hash chains,
plus symbolic references to them.

   This is EASY to understand and use, and it facilitates the next thing:

 - git makes it easy to minimize the scope and complexity of merges by
making workflows possible where downstreams rebase constantly so as to
keep their commits "on top" of the upstreams' latest master branch.
This minimizes merge complexity for downstreams and eliminates it for
most upstreams (where most merges are "fast-foward" merges).

There are other features.  And yes, the ease with which one can get
git public repos hosted for free at github/gitlab/gitorious/... is
very, very nice.  And the tooling those sites provide is very, very,
very nice.  But really, the key is that git facilitates every
workflow, particularly merge-minimizing workflows.

There's other things, but they are less important.  Finally, there's this:

 - network effects.

Git has sucked all the oxygen out of the room for the other VCSes.  If
you loved SVN, well, too bad; the rest of the world has moved on.  You
can see it as similar to JavaScript winning if you like (I don't), and
go sulk in a corner.  Non-git VCS usage is now niche usage.

The flip side, of course, is that continuing to use non-git VCSes for
public projects fails to take advantage of git's positive network
effects.  Therefore sticking to not-git -> less cooperation.  You can
go browse the git-based repo hosting sites and observe this for
yourself by comparing to the others.

I hate to make the "it's the popular kid and we all want to be
popular" argument.  But if it helps win you over, I don't mind.

Of course, SVN is one of the most difficult-to-use VCSes out there.
So there's that.

I simply don't have the time to bring myself to attempt to re-learn
SVN (and suffer its awful and storage-heavy branching model) just to
contribute something to xml2rfc -- if I have to do that, then I just
won't do it at all.  Call this a juvenile attitude if you like, but
it's the truth; there are more interesting and deserving git-hosted
open source projects to contribute to, and I can easily discover them.
Every minute of extra time I have for contributions is extremely
valuable, so I choose carefully.  The network effect says: most
would-be contributors are just like me in this sense.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 19:15:01 +0200

On 2014-06-12 18:43, Nico Williams wrote:
> ...

Ahem.

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 Jun 2014 12:28:47 -0500

>>     This is EASY to understand and use, and it facilitates the next thing:

I know those who dislike git are loud and think this makes git
difficult to understand.  But I find this the easiest way to
understand version control.  It's what makes rebasing easy, for
example.  And, of course, master repos must not allow symbolic names
to move in any way around the tree, just down a straight line/chain.

That's the a concise and fairly complete summary of what git is, and
it expresses its full power as well.  I do believe the users on this
list can grasp it too.

With the others you have a downright paternalistic attitude from the
VCS, trying to hem you in and contain you.  git supports lots of
workflows; the others many fewer.

People with git horror stories tend to misunderstand the (admittedly
horrible) git reset command.  But as long as you've committed your
changes, then there they are, always available for you to find them
(just don't git prune, which you wouldn't).  With the other VCSes it's
also easy to get confused, but because the machinery is hidden from
the user, the user can't think their way out of whatever box they get
themselves stuck in.  At least that's my experience: git lets me think
my way out of any bind, the others require finding someone who knows,
a stackoverflow answer to a similar problem, some blog covering it.

Nico
--

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jun 2014 10:32:51 -0700

>>     This is EASY to understand and use, and it facilitates the next thing:

I don't think that pursuing this line is productive at all.

Nico has hit the nail on the head when he talks about network effects.
And though dkg is probably right to be cautious about github, I find
that the benefit derived from network effects there vastly outweighs
the drawbacks.  The same argument applies to the git tool, though to a
lesser extent.

One of the major reasons that github has worked for HTTPbis is the
accessibility it brings.  There are far more people watching github,
far more who are familiar with the tool and therefore far more who
willingly contribute to improving the spec.  Github lists 37
contributors to HTTP/2:
https://github.com/http2/http2-spec/graphs/contributors

BTW, I do find the ability to work on the plane to be highly
advantageous.  I find the ease with which I can manage concurrent
change sets to be superior to any other VCS system I've ever used.

It hasn't been mentioned yet, but the supporting tools are also very
good.  We've just started using Travis CI for building an editor's
copy of the spec.  That is working out brilliantly.  Pull requests are
checked for sanity and pushes to the master branch are automatically
built and uploaded onto a web page.

Finally, github is fast.  I simply cannot work with the *.ietf.org
tools: they are frustrating primarily because they are extremely slow.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 19:33:40 +0200

> a stackoverflow answer to a similar problem, some blog covering it.

Well. My experience is exactly the opposite. I'm familiar with SVN. It 
allows me to do what I want, and if there's a problem I usually quickly 
find a way out.

When I use git and do something more complicated than "update, modify, 
commit" I frequently find myself in a maze of incomprehensible error 
messages, command lines, advice etc. And yes, I understand that if I 
used git more, things would be better. It's just not true that git in 
any way is "easier" than svn.

Best regards, Julian

PS: partial checkouts, anyone? Ever tried to clone a 1GB git repo over a 
flaky, slow connection?

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 Jun 2014 12:35:33 -0500

> Sometimes, but given that both git and svn are recent (<5 years) for me, that's not accurate in this case.

SVN is 14 years old.  git is 9 years old.

> I used SourceTree, and it seems primitive relative to svn GUIs like Cornerstone.

What are those svn GUIs?  I do like SourceTree...

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 Jun 2014 12:42:51 -0500

git clone supports partial cloning.

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 Jun 2014 12:52:23 -0500

On Thu, Jun 12, 2014 at 12:33 PM, Julian Reschke <[email-masked]> wrote:
> messages, command lines, advice etc. And yes, I understand that if I used
> git more, things would be better. It's just not true that git in any way is
> "easier" than svn.

The key is to think of git as a bag of commits forming a tree, with
branches being symbolic names for specific commits (which move when
you've got a branch checked out and you add a commit).

With that model in mind the rest is easy.

You have the local repo in .git, you have you files checked out in
your workspace.  You edit, add, commit, repeat.

If ever you want to break up as-yet uncommitted changes use git add -p
or git add -e, commit, then repeat until no uncommitted changes
remain.

If ever you want to discard changes, use "git checkout -- files" (NOT
git reset; stay away from git reset).

If the upstream adds commits, just commit any extant work then "git
fetch origin; git rebase origin/master" -- if you don't name the
upstream origin, change that in that command; ditto the master branch
name.

If ever you want to edit as-yet-unpushed commits just find a commit
that's a parent of the oldest one you want to edit and use git rebase
-i.

If you get lost use "git reflog": it tells you what you've done an
helps you find commits you've left unreachable from symbolic (branch,
tag) names.

That's it.  That's all you need to know.  The manpage verbiage is
easier to decipher when you think of git this way.  You're thinking
your way through and the commands are just tools.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Jun 2014 13:20:47 -0700

> SVN is 14 years old.  git is 9 years old.

And I didn't start using them when they first came out; I waited until they seemed useful to my work. If you think that makes me look stupid or old-fashioned, fine. However, I am *constantly* finding IETFers who have not used either as well. This thread is about changing to git *for IETF use*, not *for people who already like git*.

The rest of thread on "I understand Merkle trees, so every one will too" misses the same point. You understand git in a way that works well for you; that's great. For me, even though I understand Merkle trees, git has things that make my work harder when I use it, so I stay with svn. When forced to use GitHub, I do (barely); fortunately, no one has forced me to use git for work so far.

> What are those svn GUIs?  I do like SourceTree...

Mac-only: I use Cornerstone all the time. Earlier, I used Versions. Both are expensive ($60), and both were easily worth the money for my day-to-day work. The downside is that both have slow tech support. YMMV.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 Jun 2014 18:02:40 -0500

>> SVN is 14 years old.  git is 9 years old.

Oops, I misread what you wrote.  My apologies.

> The rest of thread on "I understand Merkle trees, so every one will too" misses the same point. You understand git in a way that works well for you; that's great. For me, even though I understand M…

Interesting.  Can you elaborate?  Perhaps in a new thread, or perhaps off-list?

If someone said it, I would agree that "a bad of commits forming a
Merkle tree(s)" is a bit... focused on design and implementation
details, but it's also about what every modern VCS does (Fossil,
Mercurial, git, ...).  I find that trying to sugar-coat this just
makes things worse, not better.  This is a detail that is foundational
and best exposed rather than hidden -- fixing booboos is so much
easier when this is exposed and understood than when it's hidden.

> Mac-only: I use Cornerstone all the time. Earlier, I used Versions. Both are expensive ($60), and both were easily worth the money for my day-to-day work. The downside is that both have slow tech s…

I believe it.  The tortoise* GUIs never worked for me.  SourceTree is
the first VCS GUI I've ever enjoyed and which felt natural (though I
don't like its workspace view, but hey).  Thanks,

Nico
--

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 13 Jun 2014 09:41:55 +0000

Hi,

a quick re-focusing. My original email was triggered because of frustrations with hacking on the datatracker code, which is kept in an svn repo. As are most other IETF tools projects. We have trac integration here, which is quite OK (although trac is getting dated.)

So the "svn vs. git" subject should be read as "should we stick with git for IETF tools development, or move to git." Someone offered to teach me git-svn at the Toronto codesprint, and maybe that is the answer here for me.

A second topic is what tooling we provide *for IETF WGs* to use to support their standards work. This list probably isn't the best fit for that discussion. (Although I will say that we should just get a free org account for the IETF from the friendly folks at github.)

Lars

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Jun 2014 13:30:32 +0200

I’ve been in these “git vs svn” discussions for more than half a decade now.
Usually, I just lean back and wait for the course of time to do its work; until then git-svn does its magic for me.

The benefit for a large code project is much larger.  This does not necessarily motivate a change of platform, and there are more people who need to be on board.  So indeed, this should be a separate discussion.

All WGs are different.  So I don’t think there is a point in trying a central decision.
WGs can already decide to move their work to github (or bitbucket, which also is popular).
The only decision would be whether there is an attempt to draw these repos back to the IETF servers.
If we make this attempt, I would recommend using gitlab as the infrastructure for this, as this is a very dynamic open source project that actively addresses functionality that people like about github.
(gitlab also comes with its own lightweight issue tracker, wiki etc.; this may be a bug or a feature.)

I’m not sure we know what we would use an IETF org at github for, and I'm already afraid of the discussions we will have around the proper process to run this github org (and how to map this process to github’s limited policy controls).

Grüße, Carsten

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 13 Jun 2014 09:01:26 -0400

On 6/13/14, 7:30 AM, Carsten Bormann wrote:
> ’ve been in these “git vs svn” discussions for more than half a decade now.

Having been involved in similar workplace discussions over the past 
several years (I refuse to date myself), I want to thank everyone for 
being so, well, professional.  It may be something we assume, but I've 
not seen these discussions end well.

> I’m not sure we know what we would use an IETF org at github for, and I'm already afraid of the discussions we will have around the proper process to run this github org (and how to map this proces…

I agree - different tools are more effective for different working 
groups, and different people.  I would not want to force people to 
switch to github (or other options) but offer them options and explain 
the pros and cons of each one.

tim

(PS - a git debugging flowchart for new folks who find their repo is in 
a messy state:
https://dl.dropboxusercontent.com/u/2756938/Git%20debugging%20flowchart.png