On Wed, Jul 21, 2010 at 3:38 AM, Andrew Straw straw...@astraw.com wrote:
We could also make a meta repository that uses git submodules (somewhat akin
to svn externals).
I have to confess that I first heard of git submodules when you first
mentioned them on this list a while ago, but a
On 7/20/10 8:06 PM, Fernando Perez wrote:
On Tue, Jul 20, 2010 at 7:43 PM, John Hunterjdh2...@gmail.com 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
John Hunter jdh2...@... writes:
* 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
On Wed, Jul 21, 2010 at 6:38 AM, Andrew Straw straw...@astraw.com wrote:
On 7/20/10 8:06 PM, Fernando Perez wrote:
On Tue, Jul 20, 2010 at 7:43 PM, John Hunterjdh2...@gmail.com wrote:
The major issues I am aware of are:
* what do to about all the various subdirs of the mpl trunk
On Wed, Jul 21, 2010 at 5:38 AM, Andrew Straw straw...@astraw.com 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.
This should just take a
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
On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom md...@stsci.edu 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,
On 07/20/2010 08:30 AM, Darren Dale wrote:
On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboommd...@stsci.edu 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
On Tue, Jul 20, 2010 at 1:48 PM, Eric Firing efir...@hawaii.edu wrote:
On 07/20/2010 08:30 AM, Darren Dale wrote:
On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboommd...@stsci.edu wrote:
We've seen this before. It seems to have to do with files that were
created after the branching. While
On 07/20/2010 08:59 AM, Ryan May wrote:
On Tue, Jul 20, 2010 at 1:48 PM, Eric Firingefir...@hawaii.edu wrote:
On 07/20/2010 08:30 AM, Darren Dale wrote:
On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboommd...@stsci.edu
wrote:
We've seen this before. It seems to have to do with files
Howdy,
On Tue, Jul 20, 2010 at 11:48 AM, Eric Firing efir...@hawaii.edu wrote:
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
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
On Tue, Jul 20, 2010 at 7:43 PM, John Hunter jdh2...@gmail.com 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
13 matches
Mail list logo