question about svnmerge

Development matplotlib-devel
1

I am following the instructions in the coding guide to commit a change
on the maintenance branch, and merge that change into the trunk. I am
getting a bunch of unexpected property changes, so I interrupted the
commit. Is it ok to go ahead and let this finish?:

[~/Projects/matplotlib]
darren@...871... $ svnmerge merge -S v1_0_maint
/usr/bin/svnmerge:71: DeprecationWarning: The popen2 module is
deprecated. Use the subprocess module.
  import sys, os, getopt, re, types, tempfile, time, popen2, locale
property 'svnmerge-integrated' set on '.'

--- Merging r8566 into '.':
U CHANGELOG
U lib/matplotlib/backends/backend_qt4.py

property 'svnmerge-integrated' set on '.'

[~/Projects/matplotlib]
darren@...871... $ svn commit -F svnmerge-commit-message.txt
Sending .
Sending CHANGELOG
Sending doc/pyplots/README
Sending doc/sphinxext/gen_gallery.py
Sending doc/sphinxext/gen_rst.py
Sending examples/misc/multiprocess.py
Sending examples/mplot3d/contour3d_demo.py
Sending examples/mplot3d/contourf3d_demo.py
Sending examples/mplot3d/polys3d_demo.py
Sending examples/mplot3d/scatter3d_demo.py
Sending examples/mplot3d/surface3d_demo.py
Sending examples/mplot3d/wire3d_demo.py
Sending lib/matplotlib/backends/backend_qt4.py
Sending lib/matplotlib/sphinxext/mathmpl.py
Sending lib/matplotlib/sphinxext/only_directives.py
Sending lib/matplotlib/sphinxext/plot_directive.py
^Csvn: Commit failed (details follow):
svn: At least one property change failed; repository is unchanged
svn: Caught signal

[~/Projects/matplotlib]
darren@...871... $ svn diff

Property changes on: .

···

___________________________________________________________________
Modified: svnmerge-integrated
   - /trunk/matplotlib:1-7315 /branches/mathtex:1-7263
/branches/v0_98_5_maint:1-7253 /branches/v0_91_maint:1-6428
/branches/v1_0_maint:1-8564
   + /branches/mathtex:1-7263 /branches/v0_91_maint:1-6428
/branches/v0_98_5_maint:1-7253 /branches/v1_0_maint:1-8566
/trunk/matplotlib:1-7315
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint:r8566

Index: CHANGELOG

--- CHANGELOG (revision 8566)
+++ CHANGELOG (working copy)
@@ -1,3 +1,5 @@
+2010-07-20 Return Qt4's default cursor when leaving the canvas - DSD
+
2010-07-06 Tagging for mpl 1.0 at r8502

Property changes on: doc/sphinxext/gen_gallery.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/doc/sphinxext/gen_gallery.py:r8566

Property changes on: doc/sphinxext/gen_rst.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/doc/sphinxext/gen_rst.py:r8566

Property changes on: doc/pyplots/README
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/doc/pyplots/README:r8566

Property changes on: lib/matplotlib/sphinxext/plot_directive.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/plot_directive.py:r8566

Property changes on: lib/matplotlib/sphinxext/mathmpl.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/mathmpl.py:r8566

Property changes on: lib/matplotlib/sphinxext/only_directives.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/only_directives.py:r8566

Property changes on:
lib/matplotlib/tests/baseline_images/test_spines/spines_axes_positions.png
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/lib/matplotlib/tests/baseline_images/test_spines/spines_axes_positions.png:r8566

Index: lib/matplotlib/backends/backend_qt4.py

--- lib/matplotlib/backends/backend_qt4.py (revision 8566)
+++ lib/matplotlib/backends/backend_qt4.py (working copy)
@@ -150,6 +150,7 @@
         FigureCanvasBase.enter_notify_event(self, event)

     def leaveEvent(self, event):
+ QtGui.QApplication.restoreOverrideCursor()
         FigureCanvasBase.leave_notify_event(self, event)

     def mousePressEvent( self, event ):

Property changes on: examples/mplot3d/contourf3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/contourf3d_demo.py:r8566

Property changes on: examples/mplot3d/scatter3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/scatter3d_demo.py:r8566

Property changes on: examples/mplot3d/polys3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/polys3d_demo.py:r8566

Property changes on: examples/mplot3d/wire3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/wire3d_demo.py:r8566

Property changes on: examples/mplot3d/surface3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/surface3d_demo.py:r8566

Property changes on: examples/mplot3d/contour3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/contour3d_demo.py:r8566

Property changes on: examples/misc/multiprocess.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/misc/multiprocess.py:r8566

2

We've seen this before. It seems to have to do with files that were created after the branching. While I haven't found a solution, it's been going on a long time and seems to be benign.

(And, yeah, making the leap to a DVCS would probably not be a bad "solution" to this problem.)

Mike

···

On 07/20/2010 10:14 AM, Darren Dale wrote:

I am following the instructions in the coding guide to commit a change
on the maintenance branch, and merge that change into the trunk. I am
getting a bunch of unexpected property changes, so I interrupted the
commit. Is it ok to go ahead and let this finish?:

[~/Projects/matplotlib]
darren@...871... $ svnmerge merge -S v1_0_maint
/usr/bin/svnmerge:71: DeprecationWarning: The popen2 module is
deprecated. Use the subprocess module.
   import sys, os, getopt, re, types, tempfile, time, popen2, locale
property 'svnmerge-integrated' set on '.'

--- Merging r8566 into '.':
U CHANGELOG
U lib/matplotlib/backends/backend_qt4.py

property 'svnmerge-integrated' set on '.'

[~/Projects/matplotlib]
darren@...871... $ svn commit -F svnmerge-commit-message.txt
Sending .
Sending CHANGELOG
Sending doc/pyplots/README
Sending doc/sphinxext/gen_gallery.py
Sending doc/sphinxext/gen_rst.py
Sending examples/misc/multiprocess.py
Sending examples/mplot3d/contour3d_demo.py
Sending examples/mplot3d/contourf3d_demo.py
Sending examples/mplot3d/polys3d_demo.py
Sending examples/mplot3d/scatter3d_demo.py
Sending examples/mplot3d/surface3d_demo.py
Sending examples/mplot3d/wire3d_demo.py
Sending lib/matplotlib/backends/backend_qt4.py
Sending lib/matplotlib/sphinxext/mathmpl.py
Sending lib/matplotlib/sphinxext/only_directives.py
Sending lib/matplotlib/sphinxext/plot_directive.py
^Csvn: Commit failed (details follow):
svn: At least one property change failed; repository is unchanged
svn: Caught signal

[~/Projects/matplotlib]
darren@...871... $ svn diff

Property changes on: .
___________________________________________________________________
Modified: svnmerge-integrated
    - /trunk/matplotlib:1-7315 /branches/mathtex:1-7263
/branches/v0_98_5_maint:1-7253 /branches/v0_91_maint:1-6428
/branches/v1_0_maint:1-8564
    + /branches/mathtex:1-7263 /branches/v0_91_maint:1-6428
/branches/v0_98_5_maint:1-7253 /branches/v1_0_maint:1-8566
/trunk/matplotlib:1-7315
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint:r8566

Index: CHANGELOG

--- CHANGELOG (revision 8566)
+++ CHANGELOG (working copy)
@@ -1,3 +1,5 @@
+2010-07-20 Return Qt4's default cursor when leaving the canvas - DSD
+
  2010-07-06 Tagging for mpl 1.0 at r8502

Property changes on: doc/sphinxext/gen_gallery.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/doc/sphinxext/gen_gallery.py:r8566

Property changes on: doc/sphinxext/gen_rst.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/doc/sphinxext/gen_rst.py:r8566

Property changes on: doc/pyplots/README
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/doc/pyplots/README:r8566

Property changes on: lib/matplotlib/sphinxext/plot_directive.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/plot_directive.py:r8566

Property changes on: lib/matplotlib/sphinxext/mathmpl.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/mathmpl.py:r8566

Property changes on: lib/matplotlib/sphinxext/only_directives.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/only_directives.py:r8566

Property changes on:
lib/matplotlib/tests/baseline_images/test_spines/spines_axes_positions.png
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/lib/matplotlib/tests/baseline_images/test_spines/spines_axes_positions.png:r8566

Index: lib/matplotlib/backends/backend_qt4.py

--- lib/matplotlib/backends/backend_qt4.py (revision 8566)
+++ lib/matplotlib/backends/backend_qt4.py (working copy)
@@ -150,6 +150,7 @@
          FigureCanvasBase.enter_notify_event(self, event)

      def leaveEvent(self, event):
+ QtGui.QApplication.restoreOverrideCursor()
          FigureCanvasBase.leave_notify_event(self, event)

      def mousePressEvent( self, event ):

Property changes on: examples/mplot3d/contourf3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/examples/mplot3d/contourf3d_demo.py:r8566

Property changes on: examples/mplot3d/scatter3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/examples/mplot3d/scatter3d_demo.py:r8566

Property changes on: examples/mplot3d/polys3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/examples/mplot3d/polys3d_demo.py:r8566

Property changes on: examples/mplot3d/wire3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/examples/mplot3d/wire3d_demo.py:r8566

Property changes on: examples/mplot3d/surface3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/examples/mplot3d/surface3d_demo.py:r8566

Property changes on: examples/mplot3d/contour3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/examples/mplot3d/contour3d_demo.py:r8566

Property changes on: examples/misc/multiprocess.py
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /branches/v1_0_maint/examples/misc/multiprocess.py:r8566

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

3

We've seen this before. It seems to have to do with files that were
created after the branching. While I haven't found a solution, it's
been going on a long time and seems to be benign.

Ok, thanks.

(And, yeah, making the leap to a DVCS would probably not be a bad
"solution" to this problem.)

I was going to ask when the transition might occur, then decided against it.

When might the transition occur?

···

On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom <mdroe@...31...> wrote:

4

Although I would like the transition to occur soon, it might make sense to let the numpy people do it first so that we can take maximum advantage of their systematic approach. I don't know how much of a delay that would entail, but it might provide us with a nice ready-made set of instructions, saving us from some thrashing around.

If Mike or Andrew or anyone else proficient in svn and git has the time to make the jump earlier, though, I wouldn't object. I can't help much, if at all, with the transition myself, and I will need some simple recipes (very mpl-specific, like the present instructions for taming the svnmerge monster) for the git workflow. I understand the basic ideas, and work routinely with mercurial, but git will take some practice. (It is possible that I will be able to use hggit, but usually there are gotchas with such translation interfaces, and using the native system ends up being the better course of action.)

Eric

···

On 07/20/2010 08:30 AM, Darren Dale wrote:

On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom<mdroe@...31...> wrote:

We've seen this before. It seems to have to do with files that were
created after the branching. While I haven't found a solution, it's
been going on a long time and seems to be benign.

Ok, thanks.

(And, yeah, making the leap to a DVCS would probably not be a bad
"solution" to this problem.)

I was going to ask when the transition might occur, then decided against it.

When might the transition occur?

5

I can't speak to what the NumPy folk are doing, but I can say that
moving the trunk of one of my small subversion projects over to git
was as easy as:

0) Create authors.txt to map svn committers to git committers
1) Checkout svn trunk using git-svn (which results in a git repo)
2) Push to github

I was really surprised.

Ryan

···

On Tue, Jul 20, 2010 at 1:48 PM, Eric Firing <efiring@...229...> wrote:

On 07/20/2010 08:30 AM, Darren Dale wrote:

On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom<mdroe@...31...> wrote:

We've seen this before. It seems to have to do with files that were
created after the branching. While I haven't found a solution, it's
been going on a long time and seems to be benign.

Ok, thanks.

(And, yeah, making the leap to a DVCS would probably not be a bad
"solution" to this problem.)

I was going to ask when the transition might occur, then decided against it.

When might the transition occur?

Although I would like the transition to occur soon, it might make sense
to let the numpy people do it first so that we can take maximum
advantage of their systematic approach. I don't know how much of a
delay that would entail, but it might provide us with a nice ready-made
set of instructions, saving us from some thrashing around.

If Mike or Andrew or anyone else proficient in svn and git has the time
to make the jump earlier, though, I wouldn't object. I can't help much,
if at all, with the transition myself, and I will need some simple
recipes (very mpl-specific, like the present instructions for taming the
svnmerge monster) for the git workflow. I understand the basic ideas,
and work routinely with mercurial, but git will take some practice. (It
is possible that I will be able to use hggit, but usually there are
gotchas with such translation interfaces, and using the native system
ends up being the better course of action.)

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

6

We've seen this before. It seems to have to do with files that were
created after the branching. While I haven't found a solution, it's
been going on a long time and seems to be benign.

Ok, thanks.

(And, yeah, making the leap to a DVCS would probably not be a bad
"solution" to this problem.)

I was going to ask when the transition might occur, then decided against it.

When might the transition occur?

Although I would like the transition to occur soon, it might make sense
to let the numpy people do it first so that we can take maximum
advantage of their systematic approach. I don't know how much of a
delay that would entail, but it might provide us with a nice ready-made
set of instructions, saving us from some thrashing around.

If Mike or Andrew or anyone else proficient in svn and git has the time
to make the jump earlier, though, I wouldn't object. I can't help much,
if at all, with the transition myself, and I will need some simple
recipes (very mpl-specific, like the present instructions for taming the
svnmerge monster) for the git workflow. I understand the basic ideas,
and work routinely with mercurial, but git will take some practice. (It
is possible that I will be able to use hggit, but usually there are
gotchas with such translation interfaces, and using the native system
ends up being the better course of action.)

I can't speak to what the NumPy folk are doing, but I can say that
moving the trunk of one of my small subversion projects over to git
was as easy as:

Yes, but there is a *lot* more involved in making the transition than just creating a git replica of the svn trunk.

Eric

···

On 07/20/2010 08:59 AM, Ryan May wrote:

On Tue, Jul 20, 2010 at 1:48 PM, Eric Firing<efiring@...229...> wrote:

On 07/20/2010 08:30 AM, Darren Dale wrote:

On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom<mdroe@...31...> wrote:

0) Create authors.txt to map svn committers to git committers
1) Checkout svn trunk using git-svn (which results in a git repo)
2) Push to github

I was really surprised.

Ryan

7

Howdy,

Although I would like the transition to occur soon, it might make sense
to let the numpy people do it first so that we can take maximum
advantage of their systematic approach. I don't know how much of a
delay that would entail, but it might provide us with a nice ready-made
set of instructions, saving us from some thrashing around.

Matthew Brett wrote a set of instructions meant to be easily re-used
by any project:

Here's the one for ipython:

http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html

The idea is to have one workflow we agree on (for nipy and ipython, so
far), but generate docs whose URLs are correct for each project, so
people can copy/paste easily from the docs.

Cheers,

f

···

On Tue, Jul 20, 2010 at 11:48 AM, Eric Firing <efiring@...229...> wrote:

8

Yes, but there is a *lot* more involved in making the transition than
just creating a git replica of the svn trunk.

Granted, and I'm probably forgetting many of them. So it is probably
a good idea for us to enumerate them here as a checklist when we do
migrate.

The major issues I am aware of are:

* what do to about all the various subdirs of the mpl trunk
(trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to
one tags all with a unique revision number. In git, how do we
synchronize between them? Putting them all in the same tree would be
monolithic and require huge checkouts. Unlike svn, in git it is
difficult/impossible to check out just a subdir (eg trunk/matplotlb)
and also commit to it. So we might end up having to informally
synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in
the CHANGELOG or release notes.

* we have to port the sample_data handling. Jouni has shown that the
viewvc ETags in sf and github work the same way, so this should be a
minor hurdle.

* organizational stuff: how do we handle the notion of the central
repo? Now that github support "organizations" this should be
relatively easy. Andrew and I registered a matplotlib user acct at
github and created a gmail acct mplgithub as a central administrator
(matplotlib@...149... was taken, the bastards). Email me offlist if
you are interested in obtaining the passwd for the github or gmail
admin accts -- but you should probably coordinate with Andrew who is
our point person as soon as he re-emerges.

* porting the buildbot to work w/ github commits

* related: porting the trunkdocs build to work with github commits

* how to handle the svn tree at sf -- should it mirror the new github
tree or remain stale or simply removed?

Please add to the list other issues that need to be handled.

Of all these, I'm only concerned philosophically with the first. The
others are matters of time and work as people make the transition to
the new server. The first seems like a true potential workflow
impediment for those who run off svn/git HEAD and analogues.

JDH

9

The major issues I am aware of are:

* what do to about all the various subdirs of the mpl trunk
(trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to
one tags all with a unique revision number. In git, how do we
synchronize between them? Putting them all in the same tree would be
monolithic and require huge checkouts. Unlike svn, in git it is
difficult/impossible to check out just a subdir (eg trunk/matplotlb)
and also commit to it. So we might end up having to informally
synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in
the CHANGELOG or release notes.

Probably using a common tag across repos would be the easiest. Any
time you want a known 'sync point', you tag all the relevant repos
with the same tag. It then becomes very simple to write a little
script that will update checkout a bunch of repos sitting in the same
parent directory (each as its own dir, of course) at a common tag.
You can make up a convention for these special tags so that they are
always named with a given pattern (you could even use rNNNN if you
wanted).

* organizational stuff: how do we handle the notion of the central
repo? Now that github support "organizations" this should be
relatively easy. Andrew and I registered a matplotlib user acct at
github and created a gmail acct mplgithub as a central administrator
(matplotlib@...149... was taken, the bastards). Email me offlist if
you are interested in obtaining the passwd for the github or gmail
admin accts -- but you should probably coordinate with Andrew who is
our point person as soon as he re-emerges.

No need. Organizations let you designate more than one 'owner', so you
can mark more than one person with full admin privileges without
having to give out the password around. I recently converted the
extra ipython account to an organization, added Brian Granger as a
second 'owner', and that's it. You can then make as many teams and
repos as you want within an organization. The github org model is
fairly simple but very effective (much nicer than how launchpad uses
teams).

* porting the buildbot to work w/ github commits

* related: porting the trunkdocs build to work with github commits

* how to handle the svn tree at sf -- should it mirror the new github
tree or remain stale or simply removed?

I would freeze it during a transition period and later on make a
static backup of teh repo dump somewhere for historical purposes (and
just in case, disk is cheap). I would then nuke it for simplicity of
administration, since on github people can still use svn if they want
to track a git repo:

I should note that I have not used this in practice, but a quick and
dirty test with the ipython repo seems to work (you just get the
master git branch though):

amirbar[junk]> svn checkout http://svn.github.com/ipython/ipython.git

[...]

amirbar[junk]> cd ipython.git/
amirbar[ipython.git]> svn info
Path: .
URL: http://svn.github.com/ipython/ipython.git
Repository Root: http://svn.github.com/ipython/ipython.git
Repository UUID: e94b1212-8258-e27c-589c-ce57b7db7bff
Revision: 2611
Node Kind: directory
Schedule: normal
Last Changed Author: fernando.perez
Last Changed Rev: 2611

Please add to the list other issues that need to be handled.

Of all these, I'm only concerned philosophically with the first. The
others are matters of time and work as people make the transition to
the new server. The first seems like a true potential workflow
impediment for those who run off svn/git HEAD and analogues.

Others with more git expertise may suggest a different workflow, but
for that the tags approach, along with a couple of simple script
helpers to make creation/checkout of these tags a one-line operation,
seems like it should do the job.

Cheers,

f

···

On Tue, Jul 20, 2010 at 7:43 PM, John Hunter <jdh2358@...149...> wrote:

10

   

The major issues I am aware of are:

* what do to about all the various subdirs of the mpl trunk
(trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to
one tags all with a unique revision number. In git, how do we
synchronize between them? Putting them all in the same tree would be
monolithic and require huge checkouts. Unlike svn, in git it is
difficult/impossible to check out just a subdir (eg trunk/matplotlb)
and also commit to it. So we might end up having to informally
synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in
the CHANGELOG or release notes.
     

Probably using a common tag across repos would be the easiest. Any
time you want a known 'sync point', you tag all the relevant repos
with the same tag. It then becomes very simple to write a little
script that will update checkout a bunch of repos sitting in the same
parent directory (each as its own dir, of course) at a common tag.
You can make up a convention for these special tags so that they are
always named with a given pattern (you could even use rNNNN if you
wanted).
   

We could also make a meta repository that uses git submodules (somewhat akin to svn externals). Each commit in a repo that links to submodules specifies a specific revision of the submodule repo, so this meta repository would be a fairly natural way of linking across several repositories at specific revisions. That being said, a convention to simply use the standard git tags would also work fine, and wouldn't require people to learn git submodules. So, it's really a question of sticking to a convention (that has a lesser learning curve) or using a new set of commands that would more or less do exactly what we want, but would have to be learned. I'm agnostic on the issue.

* organizational stuff: how do we handle the notion of the central
repo? Now that github support "organizations" this should be
relatively easy. Andrew and I registered a matplotlib user acct at
github and created a gmail acct mplgithub as a central administrator
(matplotlib@...149... was taken, the bastards). Email me offlist if
you are interested in obtaining the passwd for the github or gmail
admin accts -- but you should probably coordinate with Andrew who is
our point person as soon as he re-emerges.
     

No need. Organizations let you designate more than one 'owner', so you
can mark more than one person with full admin privileges without
having to give out the password around. I recently converted the
extra ipython account to an organization, added Brian Granger as a
second 'owner', and that's it. You can then make as many teams and
repos as you want within an organization. The github org model is
fairly simple but very effective (much nicer than how launchpad uses
teams).
   

I went ahead and switched our github.com/matplotlib account into an organization when github announced organization support a few weeks ago. Just now I added the jdh2358 and fperez users into the matplotlib owner's team.

(And I'm trying to re-emerge, I promise...)

* porting the buildbot to work w/ github commits
     

I should be able to handle that fairly easily. I do it for my other projects. (Bigger on my buildbot priority list is stopping the annoying occasional config directory multi-process conflict.

* related: porting the trunkdocs build to work with github commits
     

As this is run by the buildbot, it should be taken care of with the above.

For me, the main remaining issue is how do we want to pull the svn repo into git? Right now, the unofficial git repo at github.com/astraw/matplotlib is too big for my likes because it has a lot of stuff besides the matplotlib source code and its history. Before moving to an official git repository, I think we should prune down the main repository to just the source code files, their history, and no binary files. But then that leaves the question of what to do with the binary files.

-Andrew

···

On 7/20/10 8:06 PM, Fernando Perez wrote:

On Tue, Jul 20, 2010 at 7:43 PM, John Hunter<jdh2358@...149...> wrote:

11

Is it possible to do both simultaneously for a while, to test whether
submodules works for us in practice? I have long been interested in
using something along the lines of submodules or nested repositories,
and a metarepository would seem to be exactly what we need. But this
business about cloning yielding empty submodules until you initialize
them, but then they are detached heads, remembering not using trailing
slashes when staging changes in a superproject... hopefully these will
not be issues, but we might need some time before we decide whether we
like submodules enough to embrace it long term.

I just finished a long run at work, and should have some time in the
next couple weeks during evenings and weekends that I could contribute
to the git and python3 transitions.

Darren

···

On Wed, Jul 21, 2010 at 6:38 AM, Andrew Straw <strawman@...36...> wrote:

On 7/20/10 8:06 PM, Fernando Perez wrote:

On Tue, Jul 20, 2010 at 7:43 PM, John Hunter<jdh2358@...149...> wrote:

The major issues I am aware of are:

* what do to about all the various subdirs of the mpl trunk
(trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to
one tags all with a unique revision number. In git, how do we
synchronize between them? Putting them all in the same tree would be
monolithic and require huge checkouts. Unlike svn, in git it is
difficult/impossible to check out just a subdir (eg trunk/matplotlb)
and also commit to it. So we might end up having to informally
synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in
the CHANGELOG or release notes.

Probably using a common tag across repos would be the easiest. Any
time you want a known 'sync point', you tag all the relevant repos
with the same tag. It then becomes very simple to write a little
script that will update checkout a bunch of repos sitting in the same
parent directory (each as its own dir, of course) at a common tag.
You can make up a convention for these special tags so that they are
always named with a given pattern (you could even use rNNNN if you
wanted).

We could also make a meta repository that uses git submodules (somewhat
akin to svn externals). Each commit in a repo that links to submodules
specifies a specific revision of the submodule repo, so this meta
repository would be a fairly natural way of linking across several
repositories at specific revisions. That being said, a convention to
simply use the standard git tags would also work fine, and wouldn't
require people to learn git submodules. So, it's really a question of
sticking to a convention (that has a lesser learning curve) or using a
new set of commands that would more or less do exactly what we want, but
would have to be learned. I'm agnostic on the issue.

12

This should just take a couple of minutes. Just set MPLCONFIGDIR to
be a unique dir for each buildbot on the shell line that runs the
tests.

JDH

···

On Wed, Jul 21, 2010 at 5:38 AM, Andrew Straw <strawman@...36...> wrote:

I should be able to handle that fairly easily. I do it for my other
projects. (Bigger on my buildbot priority list is stopping the annoying
occasional config directory multi-process conflict.

13

I have to confess that I first heard of git submodules when you first
mentioned them on this list a while ago, but a reasonable amount of
reading left me with the feeling that it was far more git-fu than I
was willing to handle for everyday work. They seemed like a fairly
complex system, with a very nasty set of failure modes (easy to make
mistakes having serious consequences). I say this as the guy who's
been raving about git to anyone who won't shut me up, but git
submodules seemed just a tad much.

Maybe I just didn't find the right explanation, or it was my natural
slowness, but I found all the descriptions to be confusing, with lots
of moving parts and many things to remember carefully. The tags
approach is certainly simple-minded, but it seemed easy enough and
something that one or two shell scripts would turn into mindless
one-liners in day-to-day practice, I think.

Glad to have you around again :slight_smile:

Cheers,

f

···

On Wed, Jul 21, 2010 at 3:38 AM, Andrew Straw <strawman@...36...> wrote:

We could also make a meta repository that uses git submodules (somewhat akin
to svn externals).