develooper Front page | perl.perl5.porters | Postings from July 2007

VCS for Perl 5, refocus please

Thread Next
Rafael Garcia-Suarez
July 12, 2007 05:15
VCS for Perl 5, refocus please
Message ID:
The current discussion on VCS goes nowhere, because it focuses on
technicalities rather than on the practical side of the situation.

What we want, technically, is:
1. something that does branching and merging at least as well as
2. something in which we can import the complete Perforce repository,
   including branching metadata. (and not forgetting metaconfig.)

So far, all options examined (basically svk and git) satisfy point 1. We
have no data yet about point 2, and it will need the reposithon to be
settled on. (I assume for the sake of the argument that git works or
will work soon on Windows.)

For the rest, technical arguments are distracting and irrelevant. I
consider them to be a waste of time, and off-topic for P5P.

So, given the incomplete information we have on point 2 above, I favor
an svn repository with svk or svn clients. (svk for those who have
commit access.) Here's why, and note that *none* of the following points
are based on technical reasons. They are purely social reasons.

- We have in-house support. Ask and Robert know how to make it work. exists already. Less work. More reliability.
- svn is around since a longer time; more people are familiar with it.
- Consequently, with a well-known URL in, well advertised
  on, it would be a no-brainer for most people outside the
  P5P hardcode patchers to check bleadperl out (or a subset of it, like
  pod/ or ext/Data/Dumper/).
- svk is in Perl. Public Relations. Advocacy.

Side note. I see lots of technical arguments going on about VCSes on the
list, but none that are actually critical to the proper operation of a
repository for Perl 5. (Remember that the development of Perl 5 is not
distributed. Everything in the core is tightly inderdependent. We're not
Linux or We don't have lots of public branches, nor the need for.
Neither have we to deploy often something based on the trunk. We don't
need git. Private branches are sufficient.)

Actually, the proper technical arguments, that seem to be forgotten,
are: do all clients properly handle binary files (think about and CRLF translation? Do they know about the executable
permissions on files; or, do they clobber or retain mtimes over
checkouts; or, do they clutter the working copy with horrible hidden
files or directories? That's the kind of stuff you think about, when you
have to produce a portable tarball.

So, P5Pers, focus. We don't want the best tool ever; we want the best
tool for *this* job, including its social aspects.

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About