Alan W. Irwin writes:
> Although relatively few PLplot developers are currently enthused about a
> move to a distributed version control system (DVCS), that may change in the
> future so it is important to pay attention to DVCS articles. Today, I found
> the following useful references: "Distributed Version Control Systems: A
> Not-So-Quick Guide Through" (http://www.infoq.com/articles/dvcs-guide), and
> "Merging and branching in Subversion 1.5 Upcoming release features automatic
> merge tracking -- finally!"
> (http://www.javaworld.com/javaworld/jw-01-2008/jw-01-svnmerging.html). My
> apologies Geoff if you have already mentioned one or both of these.
Nope, I haven't mentioned either of those yet. I also did a bunch of
pre-switch reading a couple years back, but as I mentioned in my first post
on the subject, nothing really prepared me for what I learned when I started
actually using them (both git on the job and svn here). That's part of why I
think the try-before-you-switch option is useful and something I should try
to support for PLplot as best I can. I'm working on it...
> The impressions I take away from just skimming these articles and some
> references they pointed to are as follows:
>
> * git is leading the pack right now of possible DVCS (distributed version
> control system) choices in terms of popularity. (This is confirmed by SF's
> support of git rather than Hg or Bzr.)
I think actually that SF does support multiple DVCS systems. I'd have to
look again, but I think that first link I posted, mentioned a couple besides
git. Checking.... Yep,
http://apps.sourceforge.net/trac/sourceforge/wiki/WikiStart
has a bullet point about half way down which says SF supports svn, git hg,
bzr and cvs.
I hope no one feels fooled that I mentioned only git. It's just that git is
the only one of those that I personally really want to see PLplot switch to.
I do think git is building a head of steam that will propell it to the front
of the pack. Well, already has, and will keep it there.
Two years ago when people talked git, they also talked interfaces on top of
git. That discussion has mostly died down by now, as git has grown not only
the DVCS versioning and transport infrastructure, but also a host of
developer work-flow assistive interfaces that pretty well cover almost
anything you'd want to do, leaving little real need for git addons at this
point. The ones that people still talk about tend to be centered around gui
or web access. I just noticed another one of these for Windows, hosted at SF.
Something about hooking git into Windows Explorer.
Anyway, if people are (or become) willing to switch, I'd really like to guide
that toward git rather than Hg or bzr. Not because I have anything against
them. Actually, I haven't used them. Rather, just because I think git is
the strong horse in the race and better to throw our lot in there than one of
the others.
BTW, I don't usually recommend originator's-advocacy type papers/books/talks,
sense they tend to be pretty zealous, maybe even slanted. That said, Linus'
ramblings on git are pretty interesting, and give you a clear view of what he
was after. If that jibes with your own views, or not, well, anyway, it
certainly gives one type of visibility. Not to be a spoiler if anyone wanted
to track those down with google, but *blazing speed* (of SCM operations) was
one of his key goals. From many independent accounts I have read, it seems
to me that git's superiority on performance metrics is pretty well
established.
The hot button for me personally, isn't speed. It's support for more
productive collaboration work flows. It's possible that Hg or bzr, which I
don't know, might support similar collaboration paradigms, since this largely
flows out of the D part of the DVCS schema. But speed is always good,
compression is always good, and company is always good. All of these seem to
point to git as the premiere DVCS, imo.
> * There still appears to be some questions about the quality of windows
> clients for git. I assume that issue will disappear in the long run due to
> the popularity of git.
>
> * git-svn is well regarded as a compromise measure so that confirms Geoff's
> use of it. Others here may want to give git-svn a try as well if you
> already have some git experience or want to acquire some.
Sorry for my silence on this issue the last few days. I've been working up
an import system for setting up a git-svn gateway. I have a couple more
kinks to work out before I put that up for others to try.
> * subversion 1.5 (the version used for the SF server, see
> http://apps.sourceforge.net/trac/sourceforge/wiki/Subversion) has much
> improved merging support. However, svn servers are backwards compatible in
> the sense that they will take on the characteristics of the (potentially
> older) version of the svn client. Thus, it is essential to use an svn-1.5
> client for those who want to take advantage of the new subversion merge
> capabilities when merging their branch changes back to trunk.
Interesting. Good to hear. I was aware of 1.5.x strains, but hadn't given
them a try yet.
--
Geoff
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
