gnuplot-beta

Re: Repository conversion

[Clark G. <cla...@fa...>]

I've been thinking for some time I might just do an hg conversion for the good of the order, at least to demonstrate. I agree with Eric - once a decision is made, you're better off to write up a little "how to" and have a flag day. Or two. ;-)

On Feb 24, 2014 10:22 AM, Daniel J Sebald <dan...@ie...> wrote:
>
> On 02/24/2014 08:30 AM, Eric S. Raymond wrote: 
>
> > (2) Where do you want to land? 
> > 
> > As bzr is now moribund, the realistic alternatives are Subversion, 
> > git, and hg.  But I mention Subversion only for completeness; the 
> > advantages of distributed VCS are huge and if you're going to incur 
> > the transition costs of moving away from CVS either git or hg would 
> > have a much higher functional payoff. 
>
> A few days ago I was thinking that perhaps a conversion to both git/hg 
> could be done and for a month the developers try to keep cvs/git/hg in 
> sync and at the end of the month decide which is preferred.  The summer 
> months are usually when there is most free time for that sort of thing. 
>
> Dan 

Re: Repository conversion

[Clark G. <cla...@fa...>]

I would certainly agree that git is apparently more prevalent than hg but both have reasonable critical mass. I wouldn't be concerned about the vitality of either. I would suggest those who are interested do a real comparison relative to how you want the project to work, and do so with an open mind relative to your preferred default.

For example one thing git does well is manage changes that do not respect file structure, whereas hg considers the file to be the artifact that is managed. I think in gnuplot the latter is consistent with how we think of the code base, but git's perspective is interesting.

I asked my most "worldly" developer to assess the two for my team's purposes. Joel Sposky's blog posts on distributed code management and his hginit.com site were also illustrative. And we decided on hg. The more seasoned devs in the group have enjoyed this decision and the ops guys live with it well (they certainly would not be more at home with git).

But in my day job I do not have to concern myself too much with the inconvenience of consensus. ;-) YMMV.

With that said, do check out Joel's post and hginit.com.

Cheers
Clark

On Feb 24, 2014 4:51 PM, Mojca Miklavec <moj...@gm...> wrote:
>
> On Mon, Feb 24, 2014 at 9:13 PM, Tait wrote:
> > "Eric S. Raymond" said (on 2014/02/24):
> >> (2) Where do you want to land?
> >>
> >> As bzr is now moribund, the realistic alternatives are Subversion,
> >> git, and hg.  But I mention Subversion only for completeness; the
> >> advantages of distributed VCS are huge and if you're going to incur
> >> the transition costs of moving away from CVS either git or hg would
> >> have a much higher functional payoff.
> >
> > I'd not heard Bazaar was moribund... they seem to be still making new
> > releases? (... However, SourceForge doesn't appear to support bzr, so
> > it's probably moot to this discussion.)
>
> While they might make new releases, the popularity lags way behind.
> (And consequently there are way less tools and services supporting
> it.) Also, Bazaar is not the only alternative, but all other tools
> have even lower popularity and adoption. So yes, discussing anything
> but those three doesn't seem worth it.
>
> > Has anyone studied/published how many projects have switched from Hg
> > to git, and vice-versa?
>
> That's difficult enough, but you can feed the search engine with
> "convert git mercurial" and figure out that just about every hit
> explains how to convert from mercurial to git. The first hit about
> conversion from git to mercurial was from the time when bitbucket was
> the only provider of free hosting of private repositories and only
> supported mercurial.
>
> > From my personal anecdotal experience, I know
> > of a couple that have hg->git (mostly due to difficulties with
> > branching), but none that have git->hg.
>
> ... which confirms the above observation.
>
> > Support for all three (#bzr, #mercurial, #git) can be had on
> > irc.freenode.net. #Git is by far the largest channel of those (for
> > whatever that's worth)
>
> The "mean" explanation would be that git must be so difficult to use
> that its users need most support ;)
>
> > and seems to have the largest list of projects
> > using it, so momentum seems to favor git there.
>
> Here are some numbers, showing about three times more git users than
> those of mercurial:
>
> http://zeroturnaround.com/rebellabs/devprod-report-revisited-version-control-systems-in-2013/
> http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bazaar&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date&to_date&hlght_date&date_fmt=%25Y-%25m
> http://wiki.bazaar.canonical.com/BzrPopularity
> http://bazaarvcs.wordpress.com/2010/02/15/bazaar-adoption-growing-strongly/
>     (they stopped writing the blog in 2012)
> http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend
>     latest counting of tags on stackoverflow – git: 37547, mercurial: 5878
>
> (In the spirit of the same argument as above about BitBucket driving
> the git->hg conversion, I would dare to claim that GitHub contributed
> a lot towards the high popularity of git.)
>
> Anyway, whatever tool (out of the three) would be chosen ... it would
> be a lot better than CVS.
>
> Mojca
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Repository conversion

[Daniel J S. <dan...@ie...>]

On 02/24/2014 04:42 PM, Clark Gaylord wrote:
> I would certainly agree that git is apparently more prevalent than hg but both have reasonable critical mass. I wouldn't be concerned about the vitality of either. I would suggest those who are interested do a real comparison relative to how you want the project to work, and do so with an open mind relative to your preferred default.
>
> For example one thing git does well is manage changes that do not respect file structure, whereas hg considers the file to be the artifact that is managed. I think in gnuplot the latter is consistent with how we think of the code base, but git's perspective is interesting.

 From my understanding, the reason that git is more flexible in terms of 
modifying past comments as pointed out by Mojca is fact that the 
underlying manner in which files are stored in git is as complete files, 
albeit hash files.  On the other hand, hg uses a series of diffs.  Thus 
hg is in more sense "immutable".

There is a bit of philosophy with this, however.  Going back through 
local changesets and making modifications to comments, etc. is one 
thing, but once the canonical version of the repository is modified it 
is best to leave that be--the reason being that there are possibly 
hundreds of other developers who have clones of that repository and 
modifying the base of the canonical version risks upsetting the apple 
cart for a lot of people.  So, once a push is done and considered 
public, it is best to be immutable.

Locally, I'm often deconstructing some sequence of two or three 
changesets and correcting things in mercurial.  From the sound of it, it 
is probably easier to do such a thing in git, but it isn't that 
difficult in hg either so long as the canonical repository is still not 
updated as a reference point to get back to.  Changesets can be 
exported/copied from one clone to another so long as their bases are the 
same.  Mercurial makes a little noise doing such a thing now and then, 
but often diffs can be imported without too much fuss.

I recently read a blog post by Steve Losh that made a good point about 
the big difference between the two systems: the look and feel.  I pretty 
much agree with that.  For me, the two differences that stood out when I 
compared git and mercurial years ago (git I have limited exposure with 
since):

1) I found hg's syntax more understandable and less cumbersome.  I 
didn't like the staging area concept of Git because it felt repetitive, 
although I'm sure there might be some simple ways of circumventing this 
staging area because git does provide so many options/configurations. 
So please point out if that is still true and a big difference between 
the two systems.

2) Mercurial has a built in html server that I really like.  Does git 
have that now?  I really like being able to go to some project's 
repository online and there is that similar, nice interface for finding 
info about recent changesets, browsing code, viewing file history, etc. 
  That really is an important part of source control.  (One of the 
nicest VCS's in terms of visual navigation is a commercial product, but 
isn't a distributed VCS but more along the lines of cvs.)

Recently I've discovered tortoisehg which is a very nice interface for 
Windows users especially.  I assume there is a tourtoisegit as well. 
So, for Windows developers, hg and git look-and-feel differences might 
hardly matter.  Also, a good merge tool is worth considering, but I 
think that might independent of the git/hg question.

Dan

Re: Repository conversion

[Tait <gnu...@t4...>]

Daniel J Sebald <dan...@ie...> said (on 2014/03/03):
>  From my understanding, the reason that git is more flexible in terms of 
> modifying past comments as pointed out by Mojca is fact that the 
> underlying manner in which files are stored in git is as complete files, 
> albeit hash files.  On the other hand, hg uses a series of diffs.  Thus 
> hg is in more sense "immutable".

I wouldn't get hung up on the difference between snapshots vs. change
sets. Assuming everything is working correctly, the two should be
equivalent. (If anything, I would say that capturing exactly the state of
the repository as it was for the developer making the commit is more
"immutable", but either approach will achieve the same end result.)

>                       ...  So, once a push is done and considered 
> public, it is best to be immutable.

This is true for either Mercurial or Git.

> ...                    For me, the two differences that stood out when I 
> compared git and mercurial years ago (git I have limited exposure with 
> since):
> 
> 1) I found hg's syntax more understandable and less cumbersome.  I 
> didn't like the staging area concept of Git because it felt repetitive, 
> although I'm sure there might be some simple ways of circumventing this 
> staging area because git does provide so many options/configurations. 
> So please point out if that is still true and a big difference between 
> the two systems.

Terminology is different (update vs. fetch/pull, clone vs checkout, etc.)
but these hurdles are trivial and will be forgotten within a couple of
weeks anyway.

The staging area and index still exist in git, and as I mentioned before,
it is a big difference that sets git apart from other tools. It is
possible to set up git aliases and habits to make the index (aka staging
area) less apparent, but if it's possible to forget the "bad habits" of
CVS and SVN one may find the index is not just useful, but essential.
There is convenience: often one finds themselves working on more than one
thing at a time, or realizing midway through a change that it ought to
instead be multiple, smaller pieces. But also there is the philosophical
argument: one ought to deliberately construct a commit, not have it thrown
together as the summation of whatever -- intentionally or not -- happens
to be different.

The counterargument, as you've pointed out, is that I can be careful and
manage my work tree myself to construct the commits I desire, thank you
very much, now please stop making me repeat myself.

I guess the agnostic would say that in one case the tool relies on you to
manipulate the filesystem to create the desired changesets (that's
Mercurial), and the other provides tools to more directly craft the
desired commit state (that's git).

> 2) Mercurial has a built in html server that I really like.  Does git 
> have that now?  I really like being able to go to some project's 
> repository online and there is that similar, nice interface for finding 
> info about recent changesets, browsing code, viewing file history, etc. 
>   That really is an important part of source control.  (One of the 
> nicest VCS's in terms of visual navigation is a commercial product, but 
> isn't a distributed VCS but more along the lines of cvs.)

Git has had a built-in web server for a long time (since mid-2006). It's
a functional, albeit not terribly pretty interface. That's balanced out
by git having much better local tools for finding info about changes,
browsing code, viewing file history, and so forth so relying on an
external web interface is not necessary. These days, github may well be
the best-known "web interface" to git, but it's obviously tied to github.

In gnuplot's case, that interface is provided by SourceForge, and the same
regardless of tool choice. So I don't think this is really a factor in the
decision. And even if gnuplot moved away from SourceForge, the
public-facing web interface would most likely not be provided by the one
built-in to either git or Mercurial.

> Recently I've discovered tortoisehg which is a very nice interface for 
> Windows users especially.  I assume there is a tourtoisegit as well. 

Yes. And other implementations that similarly integrate into the Windows
shell. And projects for Eclipse. And the usual command-line clients in
either msys or cygwin flavors. I don't think there's any noteworthy
difference between the two on this front.

> So, for Windows developers, hg and git look-and-feel differences might 
> hardly matter.

I don't think preferences among Windows developers will be any less
intense or uniquely personal than any other OS. No UI will make one
indistinguishable from another unless it forgoes the best parts of both,
leaving only a lowest common denominator. (And then, why not just stick
with SVN?)

>                 Also, a good merge tool is worth considering, but I 
> think that might independent of the git/hg question.

I'm not sure if you mean a tool for visualizing and managing diffs and
merges manually, or the algorithms driving merging within the VCS.

For the former, I've recently discovered Meld (http://meldmerge.org), and
I rather like it.

For the latter, git uses true 3-way and N-way merging, with some choices
of variations to those algorithms. Mercurial is using a true 3-way merge
as well now, although nobody seems to know what algorithms they use to do
it. (Darcs' more complex patch and merge algorithms seems to be considered
the best, fwiw.)



At the risk of carrying on too long, here's some questions you didn't
ask:
1) Why do we have version control? Who uses it?  What do they expect out
of it?

2) What's the normal work flow in the project? How are bugs fixed (to the
current version, previously released versions)? How are new features
added? What are the things that work really well or really poorly about
this process?

3) How are outside contributions accepted? (How often does this happen?)
Who deals with these, and how? What works really well or really poorly
about this process?

The answers to those questions are important, I think, to picking git or
mercurial.