On Mar 4, 2007, at 5:15 PM, Sam Vilain wrote:
James Keenan wrote:
The patch attached is really two patches in one:
1. A resubmission in patch form of my refactoring of tools/build/
ops2c.pl into lib/Parrot/Ops2c/Utils.pm and lib/Parrot/Ops2c/
Auxiliary.pm, along with a test suite in t/tools/ops2cutils/.
2. 4 new files which provide an argument for more use of Subversion
branches in Parrot development and some tools to make using branches
easier. The files being submitted for the first time are:
Why are these two changes tied together? Surely if you have a capable
feature branching system this is not necessary.
I submitted individual patches and new files last week for the
refactoring of ops2c.pl. Following the instructions in docs/
submission.pod, I edited MANIFEST to include the new files and paths.
Those patches and new files haven't been reviewed yet. When I went
to my next round of submissions, I wanted to get it done quickly
(I've been dealing with eye infections the last several days and am
tiring easily) and decided to submit a single patch. The MANIFEST
had entries for both submissions.
docs/svn_branching.pod
lib/Parrot/Subversion/BranchManager.pm
tools/util/svn_new_branch.pl
tools/util/svn_synch.pl
The method of tracking which branch has been merged does not follow
best
practices.
Several best practices have emerged with SVN and branching, when
copying
changes from one branch to another:
1. best (if the UUID matches the repository it is being stored in) -
insert a property called "svk:merge" into the merge commit which
refers
to the SVN repo UUID and revision number of the other parent commit
which Subversion was incapable of representing.
2. second best - copy revisions individually from one branch to the
other, such as "svk smerge -Il" does.
3. crappy and crack fueled -the Subversion manual's recommendation
that
you should note in the commit message which revisions you are
"merging"
when you copy changes from one part of subversion repositories to
another.
4. Option 1, except that the UUID and revision number are not
related to
the repository they are being stored in, so end up having no
meaning at
all (unless the repository they refer to is also published, and even
then it's not exactly turn-key to get history information)
Even looking at the tags that have recently been created nearby to
your
changes it is difficult to see what value this entirely novel
system adds.
It's not novel with me. I solicited advice on Perlmonks (http://
perlmonks.org/?node_id=597867) on how to synchronize a Subversion
branch with trunk. The scripts I wrote implemented one of the
options described in that Perlmonks thread, which was provided from a
fellow Perl hacker who has never steered me wrong.
My main point is this: At this point in Parrot's development, a lot
more of that development should be going on in branches rather than
in direct commits to trunk. People need tools to manager branches
effectively and, AFAICT, no one else had addressed this problem.
particle asked me to come up with something that would reflect my
experience so far with branches and that other people would find
useful. The four files I've submitted represent my attempt to
respond to particle's request.
I freely concede that what I've submitted is a hack -- and have so
conceded in the documentation. Perhaps what we should provide our
fellow Parrot hackers is a menu of choices for how to manage
branches. If so, then instead of my suggestion of lib/Parrot/
Subversion/, we should have lib/Parrot/VersionControl: a directory
which would enable people to manage branches in the Parrot repository
(a) in a variety of ways using Subversion as their client; and/or (b)
using other clients such as svk. If you would like to code up such a
tool (either (a) or (b)), then code away! After all, (i) these are
just developers' tools; they're not essential to Parrot itself; (ii)
this is Perl: TIMTOWTDI.
If we took that approach, then we could accommodate a variety of ways
to manage branches in our repository, all with the goal of getting
people to develop more in branches.
Jim Keenan
