Re: version control (RE: Getting pkgsrc)

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Mon, Nov 22, 2010 at 10:33:48AM -0600, Larson, Timothy E. wrote:
> > Fossil is worse than CVS. Git is worse than CVS for pkgsrc.
> > CVS is the best VCS for pkgsrc so far.
> 
> I understand that different VCSs may be better for different styles
> of development.  But I've often wondered by pkgsrc hasn't switched
> to SVN, since it uses basically the same model as CVS.

There are a number of reasons, I think all of them covered in
tech-repository.  In addition, here are some specific pkgsrc ones (all
down to my personal opinion, of course):

+ pkgsrc has LOTS of small files.  Less (on average per pkgsrc entry)
than it used to, but still a huge number.  Svn doesn't handle this
very well, and git has problems with this one, too.

+ migration tools could be better -- this isn't only for pkgsrc, but
is relevant for a repo in which 97% of files are relatively unvolatile,
and perhaps 2 distinct files which will get thousands of edits per year
(TODO and CHANGES-xxxx)

+ there are some problems with repo internals moving from cvs to svn
(I work with the guy who did most of the FreeBSD mods).  Joerg has
recently cleaned up our repo enormously, especially wrt branches, pkg
revisions etc but some of these remain.

+ usually people move to svn as a means to an end - for easier git
integration, for example.  I personally see svn as a bridge vcs; it
would be better to wait for the right thing, rather than to go off
half-cocked and have to migrate again in the near future

+ I'm the guy that does the pkgsrc branches, and it's down to (on the
order of) 10 minutes to tag and to branch pkgsrc.  This is down from 1
hour plus, mostly depends nowadays on network bandwidth and latency,
and is soooooo much better because of the nice project machines, and
the way that they are set up now (thanks to tls, spz and the rest of
the crew).  So if you ever want to know how your donations affect the
project, and your ease of use, this is one huge concrete example of
that -- thank you to everyone who has contributed in the past.

+ what color are the emperor's clothes?

FWIW, I chaired the "what's next for dvcs?" session at the Google
Summer of Code Mentor summit in 2009.  What I wanted to see was FUSE
frontends for each of the vcs represented there.  One of the git
proponents said they didn't think that was possible with git, since
git was a dvcs, and so there could be many different representations
of a tree. *whoosh*

My own view is that cvs isn't the best vcs out there[*]; however, it's
the best one for pkgsrc right now, and until someone comes along with
something better, there's no point in jumping to something new or
shiny, just because it is new or shiny.

Regards,
Alistair

[*] I don't think there is a "best" vcs out there.  I'd welcome the
quick branching that git provides, but I'm not happy with its
difficulties in scaling, the migration tools, or some of the bizarre
things that rebase does, for instance, or the offline commit history
issues.  I like version tags I can read and infer something - well,
lots of things, actually.  Oh, yes, I like version tags, too - early
versions of bsd.pkg.mk used to calculate whether new pkg_install tools
were needed by looking at RCS Id strings in the pkg_add binary.  But I
digress - Hg, bzr and mtn all have good points, and some sucky ones,
too.  I like the promise of fossil -- let's see how joerg gets on with
his work on this.