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

VCS for Perl 5, refocus please

Thread Next
From:
Rafael Garcia-Suarez
Date:
July 12, 2007 05:15
Subject:
VCS for Perl 5, refocus please
Message ID:
b77c1dce0707120515h376987c7m10202421954e2fb5@mail.gmail.com
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
   Perforce
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.
  svn.perl.org 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 svn.perl.org, well advertised
  on dev.perl.org, 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 X.org. 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
uupacktool.pl) 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About