matplotlib-devel Mailing List for matplotlib

Thanks. I'll have a look at these tomorrow. It's actually nice to think I'll have some more eyes on this code soon... It's a lot of work keeping up with so many examples when the changes are so fundamental.
Cheers,
Mike

Mike,
In going through examples (on transforms branch immediately before you 
made the switch), it looks like there are a couple of new bugs
in those included by backend_driver.py:
1) legend_demo.py and legend_demo2.py make spurious black blocks, which
 go away when the plots are redrawn.
2) there is a positioning problem with the table part of table_demo.py.
Both of these are seen with the Agg or gtkagg backend; I have not
checked other backends.
Eric

Migrating to the new matplotlib codebase
========================================
Michael Droettboom has spent the last several months working on the
"transforms branch" of matplotlib, in which he rewrote from the ground
up the transformation infrastructure in matplotlib, which many found
unintuitive and hard to extend. In addition to a cleaner code base,
the reorganization allows you to define your own transformations and
projections (e.g. map projections) within matplotlib. He has merged his
work into the HEAD of the svn trunk, and this will be the basis for
future matplotlib releases.
If you are a svn user, we encourage you to continue using the trunk as
before, but with the understanding that you are now truly on the
bleeding edge. Michael has made sure all the examples still pass with
the new code base, so for the vast majority of you, I expect to see
few problems. But we need to get as many people as possible using the
new code base so we can find and fix the remaining problems. We have
take the svn code used in the last stable release in the 0.91 series,
and made it a maintenance branch so we can still fix bugs and support
people who are not ready to migrate to the new transformation
infrastructure but nonetheless need access to svn bug fixes.
Using the new code
==================
To check out the trunk with the latest transforms changes:
 > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
If you already have a working copy of the trunk, your next "svn up" will
include the latest transforms changes.
Before installing, make sure you completely remove the old matplotlib
build and install directories, eg:
 > cd matplotlib
 > sudo rm -rf build
 > sudo rm -rf /usr/local/lib/python2.5/site-packages/matplotlib
 > sudo python setup.py install
Using the old svn code
======================
To check out the maintenance branch, in order to commit bugfixes to 0.91.x:
 > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint
 matplotlib_0_91_maint
Any applicable bugfixes on the 0.91.x maintenance branch should be
merged into the trunk so they are fixed there as well. Svnmerge.py
makes this process rather straightforward, but you may also manually
merge if you prefer.
Merging bugfixes on the maint branch to the trunk using svnmerge.py
-------------------------------------------------------------------
Download svnmerge.py from here:
 http://www.orcaware.com/svn/wiki/Svnmerge.py
>From the working copy of the *trunk* (svnmerge.py always pulls *to*
the current working copy), so
 > svnmerge.py merge
to pull in changes from the maintenance branch. Manually resolve any
conflicts, if necessary, test them, and then commit with
 > svn commit -F svnmerge-commit-message.txt
(Note the above will stop working when the maintenance branch is
abandoned.)
API CHANGES in the new transformation infrastructure
====================================================
While Michael worked hard to keep the API mostly unchanged while
performing what has been called "open heart surgery on matplotlib",
there have been some changes, as discussed below.
The primary goal of these changes was to make it easier to
extend matplotlib to support new kinds of projections. This is
primarily an internal improvement, and the possible user-visible
changes it allows are yet to come.
These changes are detailed in the API_CHANGES document.

On Tue, Jan 08, 2008 at 04:49:00PM -0500, Michael Droettboom wrote:
> I don't think "UR DOIN IT WRONG" is an entirely correct assessment, 
> however. Much of this change can be considered refactoring wrt to the 
> high-level public API. 
Refactoring is often defined (in test driven development) as reworking
the codebase given a complete set of tests that pass at the beginning,
and should pass at the end.
My 2 cents,
Gaël

On Jan 8, 2008 1:49 PM, Michael Droettboom <md...@st...> wrote:
> Thank you for enlightening us. This overloaded and contentious word
> will be replaced.
BTW Michael, ready to go when you are
JDH

Thank you for enlightening us. This overloaded and contentious word 
will be replaced.
I don't think "UR DOIN IT WRONG" is an entirely correct assessment, 
however. Much of this change can be considered refactoring wrt to the 
high-level public API. For instance, I believe basemap only had to 
change a handful of lines of code to work with the transforms changes. 
It's "Refactoring with some exceptional edge cases", perhaps? At the 
lower levels, where matplotlib developers are concerned, however, there 
may be some necessary changes, and that's what the API_CHANGES and other 
warnings are for. And in fact, the Wikipedia entry you point to makes 
references to lower-level interfaces being changed as the result of 
refactoring.
Anyway,
Mike
Tom Holroyd wrote:
> UR DOIN IT WRONG
> 
> http://en.wikipedia.org/wiki/Refactoring
> 
> On Tue, 2008年01月08日 at 10:48 -0800, John Hunter wrote:
> 
>> To check out the trunk with the latest transforms refactoring:
> 
> The word refactoring applies to cases of code cleanup and so on.
> Refactoring implies functional equivalence. 
> 
> Dr. Tom
> --
> There is in the world much filth: so much is true! But the world itself
> is not therefore a filthy monster! Thus spoke Zarathustra.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

UR DOIN IT WRONG
http://en.wikipedia.org/wiki/Refactoring
On Tue, 2008年01月08日 at 10:48 -0800, John Hunter wrote:
> To check out the trunk with the latest transforms refactoring:
The word refactoring applies to cases of code cleanup and so on.
Refactoring implies functional equivalence. 
Dr. Tom
--
There is in the world much filth: so much is true! But the world itself
is not therefore a filthy monster! Thus spoke Zarathustra.

On 2008年1月07日 19:54:38 -1000
Eric Firing <ef...@ha...> wrote:
> Andrew Straw wrote:
> > Something I haven't seen addressed on the numpy list (or here) is
> > using hg or bzr to mirror an svn repository. What would be the
> > added advantage to the project of using a DVCS if all the
> > DVCS-ophiles would simply sync the svn tree?
> 
> There has been numpy discussion of starting with a read-only mirror.
> My sense is that doing two-way synchronization may be possible using 
> tailor, but it doesn't sound very practical. Without two-way 
> synchronization, getting changes from the user's DVCS committed back
> to svn would be a clumsy process.
I'm all for the DVCS concept. I have recently started using git for my
own work, including reading the matplotlib repository. git includes
built-in tools to talk to svn and cvs repositories. In fact, the reason
I chose git over the alternatives (hg, bzr, etc.) is the way it allows
me to use DVCS for my own work (and, occasionally, the work of my close
collaborators) without requiring a change to an entire project's
infrastructure. Using git in this way does not allow one to take
advantage of all of the potential DVCS promises, but it goes a long way
in the right direction.
It's something to consider.
Disclaimers:
(a) I am not an active matplotlib developer.
(b) I really don't want to start a git vs. hg vs. bzr
discussion/flamewar.
--Jim Amundson

On Jan 8, 2008 8:11 AM, Michael Droettboom <md...@st...> wrote:
> Also -- we probably want a news item to say something like this:
I just added MIGRATION.txt to the trunk -- after you do the merge, we
can post this document to provide the migration instructions. I've
tried to add all your text with minor reorganization and added a
general introduction. Feel free to edit and add to this document as
you see fit, and after you do the merge and new branches, I'll post it
and update a news flash on the web site.
JDH
Migrating to the new matplotlib codebase
========================================
Michael Droettboom has spent the last several month working on the
"transforms branch" of matplotlib, in which he rewrote from the ground
up the transformation infrastructure in matplotlib, whih many found
unintuitive and hard to extend. In addition to a cleaner code base,
the refactoring allows you to define your own trasformations and
projections (eg map projections) within matplotlib. He has merged his
work into the HEAD of the svn trunk, and this will be the basis for
future matplotlib releases.
If you are a svn user, we encourage you to continue using the trunk as
before, but with the understanding that you are now truly on the
bleeding edge. Michael has made sure all the examples still pass with
the new code base, so for the vast majority of you, I except to see
few problems. But we need to get as many people as possible using the
new code base so we can find and fix the remaining problems. We have
take the svn cde used in the last stable release in the 0.91 series,
and made it a maintenance branch so we can still fix bugs and support
people who are not ready to migrate to the new transformation
infrastructure but nonetheless need acccess to svn bug fixes.
The experimental transforms refactoring changes have been merged into
SVN trunk. While this version is passing all examples and unit tests,
there may be changes that subtly break things that used to work, raise
nasty exceptions or kill innocent puppies. To help move matplotlib
forward, we encourage all users who are comfortable with the bleeding
edge to use the trunk with their own plots and report any bugs to the
mailing list.
Using the new code
==================
To check out the trunk with the latest transforms refactoring:
 > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
If you already have a working copy of the trunk, your next "svn up" will
include the latest transforms refactoring.
Using the old svn code
======================
To check out the maintenance branch, in order to commit bugfixes to 0.91.x:
 > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint
 matplotlib_0_91_maint
Any applicable bugfixes on the 0.91.x should be merged into the trunk so
they are fixed there as well.
API CHANGES in the new transformation infrastructure
====================================================
While Michael worked hard to keep the API mostly unchanged while
performing what has been called "open heart surgery on matplotlib",
there have been some changes, as discussed below.
The primary goal of this refactoring was to make it easier to
extend matplotlib to support new kinds of projections. This is
primarily an internal improvement, and the possible user-visible
changes it allows are yet to come.
These changes are detailed in the API_CHANGES document

Also -- we probably want a news item to say something like this:
====
The experimental transforms refactoring changes have been merged into 
SVN trunk. While this version is passing all examples and unit tests, 
there may be changes that subtly break things that used to work, raise 
nasty exceptions or kill innocent puppies. To help move matplotlib 
forward, we encourage all users who are comfortable with the bleeding 
edge to use the trunk with their own plots and report any bugs to the 
mailing list. If the trunk is not working for you and you just need 
something that works, download the 0.91.2 release, or check out the 
0.91.x maintenance branch from svn:
 svn co
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint 
matplotlib_0_91_maint
====
Mike
John Hunter wrote:
> Now that the 0.91.2 release is out, I am inclined to merge Michael's
> transforms branch into the trunk. Since many people rely on svn, we
> probably need to advertise this move broadly, with a news item on the
> web page and announcements on the mailing lists, with instructions on
> how to checkout the 0.91 maintenance branch (which does not exist but
> would be created as the maintenance branch). There was some
> suggestion earlier that we leave Michael's work on a branch, but I
> think we need to get it on the trunk so developers and svn users will
> get it by default which will help us move more rapidly in shaking out
> the remaining bugs and problems.
> 
> Michael, since you know more about this than anyone, you should
> probably spearhead the svn reorganization and let people know when the
> changes become effective with some advance notice. I will update the
> website with pointers to the relevant docs (your API_CHANGES and
> Changelog and the relevant svn commands and anything else you think we
> will need).
> 
> If this seems like a reasonable plan, perhaps we should shoot for
> doing this in a day or two. If any of you think this is the wrong
> approach, let us know.
> 
> JDH
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> Michael, since you know more about this than anyone, you should
> probably spearhead the svn reorganization and let people know when the
> changes become effective with some advance notice. I will update the
> website with pointers to the relevant docs (your API_CHANGES and
> Changelog and the relevant svn commands and anything else you think we
> will need).
Here's a summary of my plan:
1) Create a tag in tags/v0_91_2 of the exact revision Charlie released 
as 0.91.2. This is useful to diff against.
2) Create a branch in branches/v0_91_maint that will be used exclusively 
for bugfixes to 0.91.x, and be the source of any future 0.91.x releases.
3) Merge branches/transforms into trunk/matplotlib
Putting the most recent API_CHANGES and CHANGELOG from the transforms 
branch on the web is a good idea -- however, it should be clear that it 
applies only to SVN versions, and not the 0.91.2 release. (It's 
reasonably self-evident to me, but maybe not to everyone).
As for svn instructions (applicable after the above changes):
====
To check out the trunk with the latest transforms refactoring:
 svn co 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib 
matplotlib
If you already have a working copy of the trunk, your next "svn up" will 
include the latest transforms refactoring.
To check out the maintenance branch, in order to commit bugfixes to 0.91.x:
 svn co 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint 
matplotlib_0_91_maint
Any applicable bugfixes on the 0.91.x should be merged into the trunk so 
they are fixed there as well. I will provide further instructions about 
this (using svnmerge.py) once I have everything in place.
====
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Jan 7, 2008 2:37 PM, Eric Firing <ef...@ha...> wrote:
> 
>> (At the moment I can't compile the branch--I just sent Mike a message
>> about that off the list, with voluminous output.)
>>
>> It seems like what is needed is not exactly a merge operation but simply
>> a renaming of the trunk and the branch. Maybe some doc files need to be
>> merged, but that is about it. Correct?
> 
> Sorry if I used sloppy terminology, all I mean is that Michael's stuff
> will become the HEAD of the svn trunk, and the current HEAD of the
> trunk will become a branch. No merge will be necessary since Michael
> has been merging all changes in the HEAD into his branch on a ongoing
> basis. I don't actually know how one does this move in svn, but I
> have faith that Michael does.
I've been using svnmerge.py
http://www.orcaware.com/svn/wiki/Svnmerge.py#Quick_Usage_Overview
Essentially, it eliminates the need to remember the last points at which 
one branch was merged into another (which IMHO is the awful thing about 
svn's built-in merge). I understand this functionality will be brought 
into SVN proper in 1.5.
It also has a facility to merge the branch back into the trunk once 
we're ready. (Whether it's technically a merge or a copy, I don't 
really know -- that's where the line gets blurry. The point is, it 
should be straightforward.)
>> All this brings to mind the discussion taking place over the last week
>> on the numpy list regarding switching from svn to bzr or hg.
>> http://thread.gmane.org/gmane.comp.python.numeric.general/18130
>> (I have been using hg locally for a couple years, and I like it.) The
>> motivation is the greater ease of branching and merging with distributed
>> VCS systems in comparison to SVN. In the numpy list discussion, it
>> sounds like all participants except Travis favor making the switch.
> 
> I'm personally -1 on this. I prefer to keep things as simple as
> possible and do not see the need for a lot of branching, though there
> is clearly a need for some. svn is the standard version control
> system and has the best install base (now on OS X and all linux
> systems), making it easiest for users to get checkouts. If numpy,
> ipython and scipy all decide to move, I would probably be inclined to
> go along with it for consistency between these packages, but I
> wouldn't be leading the charge. I have never felt the need for a
> distributed version control system, personally, though some swear by
> it. It is probably because mpl has always just had a trunk with no
> branches, and I'd like to stick to that as much as possible,
> 
> Michael, how onerous was it for you to do the merges using svn -- this
> seems to be the most significant problem with svn in my reading of
> David's summary.
David Cournapeau seems to have had some non-specific bad experiences 
with svnmerge.py. I agree, it does force you to be explicit (i.e. set 
up the branch correctly from the start), unlike a DVCS where it is 
built-in. But I've had absolutely no problems with it (maybe I'm just 
lucky).
I had hesitated to add to the discussion, since so much has been said 
already over on numpy. However, besides the merge-tracking (that 
svnmerge adequately meets for me) I see one other important advantage to 
DVCS: It's easier to create local and non-official branches (meaning 
created by developers without write access to the "official" 
repository), and track changes that aren't really ready to be shared. I 
worked at a place (that shall remain nameless), that used a centralized 
VCS, but the culture (as mandated by management) was to commit to the 
trunk only very rarely, usually right before an alpha or beta cycle. 
This meant that it was a) hard to keep track of what others were doing, 
b) there was a high likelihood of conflicts with others (not just at the 
source code level, but the logical level), c) all the ad-hoc testing 
that developers do as they write code had to be completely redone after 
this "merge" and long after the developers had forgotten about what they 
had written. I'm a strong believer in "continuous integration" of code. 
 It seems to me that at its worst, a DVCS lightly discourages 
continuous integration because it makes it so easy to go off on 
tangents, and tangents aren't necessarily always a good thing if the end 
result is intended to be truly "one product". Tangents are necessary, 
yes, but their number needs to be somehow limited. This is all a matter 
of process, of course, and neither approach to version control really 
prevents any particular process -- I'd just like to make the argument 
that the "lots of little branches" process that DVCS make so easy, is 
not necessarily always appropriate.
Lastly, it seems to me that there are upteen ways to emulate a DVCS on 
top of a core repository that is still running on SVN. For instance, I 
used SVK (a DVCS specifically designed to be used in conjunction with 
SVN) in the above situation to maintain my sanity and keep my own local 
revision history. It also helps with laptop situations. Nothing is 
stopping anyone from doing that today, and we don't even need to know 
about it. I'll admit it's not really the same thing (there's would be 
no single way for someone else to get at my local changes), but it meets 
a lot of the needs with no organizational impact on others.
All this is to say, I'm sort of -0 on this -- I see as many plusses and 
negatives, I guess.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
[...]
> Michael, how onerous was it for you to do the merges using svn -- this
> seems to be the most significant problem with svn in my reading of
> David's summary.
Here is a new thread related to merging, and the difference between svn 
and a DVCS:
http://www.mail-archive.com/num...@sc.../msg05938.html
Eric

Andrew Straw wrote:
> Something I haven't seen addressed on the numpy list (or here) is using 
> hg or bzr to mirror an svn repository. What would be the added advantage 
> to the project of using a DVCS if all the DVCS-ophiles would simply sync 
> the svn tree?
There has been numpy discussion of starting with a read-only mirror. My 
sense is that doing two-way synchronization may be possible using 
tailor, but it doesn't sound very practical. Without two-way 
synchronization, getting changes from the user's DVCS committed back to 
svn would be a clumsy process.
It also seems that even one-way synchronization from a remote svn 
repository can be difficult. A little googling suggests that even 
making a read-only *svn* mirror of an svn repository is not necessarily 
as easy as one might expect.
Eric

Something I haven't seen addressed on the numpy list (or here) is using 
hg or bzr to mirror an svn repository. What would be the added advantage 
to the project of using a DVCS if all the DVCS-ophiles would simply sync 
the svn tree?
Eric Firing wrote:
> John Hunter wrote:
>> On Jan 7, 2008 2:37 PM, Eric Firing <ef...@ha...> wrote:
> [...]
>>> All this brings to mind the discussion taking place over the last week
>>> on the numpy list regarding switching from svn to bzr or hg.
>>> http://thread.gmane.org/gmane.comp.python.numeric.general/18130
>>> (I have been using hg locally for a couple years, and I like it.) The
>>> motivation is the greater ease of branching and merging with distributed
>>> VCS systems in comparison to SVN. In the numpy list discussion, it
>>> sounds like all participants except Travis favor making the switch.
>> I'm personally -1 on this. I prefer to keep things as simple as
>> possible and do not see the need for a lot of branching, though there
>> is clearly a need for some. svn is the standard version control
>> system and has the best install base (now on OS X and all linux
>> systems), making it easiest for users to get checkouts. If numpy,
>> ipython and scipy all decide to move, I would probably be inclined to
>> go along with it for consistency between these packages, but I
>> wouldn't be leading the charge. I have never felt the need for a
>> distributed version control system, personally, though some swear by
>> it. It is probably because mpl has always just had a trunk with no
>> branches, and I'd like to stick to that as much as possible,
> 
> John,
> 
> I understand your points, and this is not something I am going to push, 
> but I suspect that over the next year or two there will be a migration 
> of numpy, ipython, and scipy. Certainly there is no need for us to 
> lead, and it might be downright foolish for us to try to do so. My 
> sense, however, is that a good DVCS is something like python itself--the 
> majority of people who seriously try one get hooked.
> 
> The point of the DVCS is not to facilitate long-term branches; it is 
> still normal to have a single official version. Instead, what a DVCS 
> does is to make version control easy to use locally, regardless of 
> whether one is connected to the net or not; and to use VC while 
> experimenting with changes. A full working repository (and a very fast 
> one at that) is always available. It is extremely fast and cheap to 
> make a clone for experimentation; if things work out, the changes can be 
> propagated back to the main repo, either as they were made initially or 
> by first generating a single clean patch; and then the experimental repo 
> is deleted.
> 
> I have never used hg as a central repo in a project with more than two 
> developers (my helper and me), so I don't know exactly how it would be 
> set up, how authentication would be handled, etc. for projects like 
> numpy and mpl. What I do know is that using hg--and consequently having 
> repos for our software on all the ships we work with, and on our laptops 
> when we travel--has been a big help. I suspect that if you tried it, 
> you would find yourself liking hg for entirely private use on work for 
> your employer.
> 
> Eric
> 
>> Michael, how onerous was it for you to do the merges using svn -- this
>> seems to be the most significant problem with svn in my reading of
>> David's summary.
>>
>> JDH
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John Hunter wrote:
> On Jan 7, 2008 2:37 PM, Eric Firing <ef...@ha...> wrote:
[...]
>> All this brings to mind the discussion taking place over the last week
>> on the numpy list regarding switching from svn to bzr or hg.
>> http://thread.gmane.org/gmane.comp.python.numeric.general/18130
>> (I have been using hg locally for a couple years, and I like it.) The
>> motivation is the greater ease of branching and merging with distributed
>> VCS systems in comparison to SVN. In the numpy list discussion, it
>> sounds like all participants except Travis favor making the switch.
> 
> I'm personally -1 on this. I prefer to keep things as simple as
> possible and do not see the need for a lot of branching, though there
> is clearly a need for some. svn is the standard version control
> system and has the best install base (now on OS X and all linux
> systems), making it easiest for users to get checkouts. If numpy,
> ipython and scipy all decide to move, I would probably be inclined to
> go along with it for consistency between these packages, but I
> wouldn't be leading the charge. I have never felt the need for a
> distributed version control system, personally, though some swear by
> it. It is probably because mpl has always just had a trunk with no
> branches, and I'd like to stick to that as much as possible,
John,
I understand your points, and this is not something I am going to push, 
but I suspect that over the next year or two there will be a migration 
of numpy, ipython, and scipy. Certainly there is no need for us to 
lead, and it might be downright foolish for us to try to do so. My 
sense, however, is that a good DVCS is something like python itself--the 
majority of people who seriously try one get hooked.
The point of the DVCS is not to facilitate long-term branches; it is 
still normal to have a single official version. Instead, what a DVCS 
does is to make version control easy to use locally, regardless of 
whether one is connected to the net or not; and to use VC while 
experimenting with changes. A full working repository (and a very fast 
one at that) is always available. It is extremely fast and cheap to 
make a clone for experimentation; if things work out, the changes can be 
propagated back to the main repo, either as they were made initially or 
by first generating a single clean patch; and then the experimental repo 
is deleted.
I have never used hg as a central repo in a project with more than two 
developers (my helper and me), so I don't know exactly how it would be 
set up, how authentication would be handled, etc. for projects like 
numpy and mpl. What I do know is that using hg--and consequently having 
repos for our software on all the ships we work with, and on our laptops 
when we travel--has been a big help. I suspect that if you tried it, 
you would find yourself liking hg for entirely private use on work for 
your employer.
Eric
> 
> Michael, how onerous was it for you to do the merges using svn -- this
> seems to be the most significant problem with svn in my reading of
> David's summary.
> 
> JDH