Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Mon, Apr 13, 2009 at 11:02 PM, Martin Geisler m...@lazybytes.net wrote:

 You're right, the UI is not so good. In particular, you cannot use 'hg
 diff' to compare repositories. The rdiff extension does this, though:

  http://www.selenic.com/mercurial/wiki/index.cgi/RdiffExtension

In git, it is not just about diff, but about every command where you
would want to compare branches. From a UI POV, this vastly outweighs
the possible confusion caused by multi-branches / repo ala git. This
means everything is done within the same concept of a branch (review,
tasks, release branches, task branches, patches).


 Using stock Mercurial you can use 'hg incoming -p' to see the patches of
 the incoming (missing) changesets, or you can pull in the changesets and
 then look at them -- if you don't like them you can remove them again.

Ok, I would have to try this to get a better idea as well.


 Or you could use named branches for the numpy-1.2.x and numpy-1.3.x
 branches -- then everybody would see the branch names when they clone
 the combined repository.

Hm, ok. For release branches, named branches is the obvious choice -
it is very unlikely that you would need to delete them.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

2009/4/13 Stéfan van der Walt ste...@sun.ac.za:
 2009/4/13 Eric Firing efir...@hawaii.edu:

 Stéfan, or other git-users,

 One feature of hg that I use frequently is hg serve, the builtin web
 server.  I use it for two purposes: for temporary local publishing
 (e.g., in place of using ssh--sometimes it is quicker and easier), and
 for providing access to the very nice hgwebdir.cgi browsing capability
 on local repos.  I have looked through git commands etc., and have not
 found an equivalent; am I missing something?  The browsing capability of
 hgwebdir.cgi is much better than any gui interface I have seen for git
 or for hg.  I realize there is a gitweb.cgi, but having that cgi is not
 the same as being able to publish locally with a single command, and
 then browse.

 The command is

 git instaweb --httpd=webrick

Ah, that's nice, thanks for sharing it. I didn't know about it. Works
fine for me.

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

Stéfan van der Walt wrote:
 2009/4/13 Eric Firing efir...@hawaii.edu:
 Stéfan, or other git-users,

 One feature of hg that I use frequently is hg serve, the builtin web
 server.  I use it for two purposes: for temporary local publishing
 (e.g., in place of using ssh--sometimes it is quicker and easier), and
 for providing access to the very nice hgwebdir.cgi browsing capability
 on local repos.  I have looked through git commands etc., and have not
 found an equivalent; am I missing something?  The browsing capability of
 hgwebdir.cgi is much better than any gui interface I have seen for git
 or for hg.  I realize there is a gitweb.cgi, but having that cgi is not
 the same as being able to publish locally with a single command, and
 then browse.
 
 The command is
 
 git instaweb --httpd=webrick

Well, sort of--but one must already have one of the three supported web 
servers installed, so it is a bit heavier-weight.  The gitserve program 
is closer to hg serve because all it requires is git and python (and 
*nix, unlike hg serve).

Eric

 
 Cheers
 Stéfan
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Martin Geisler]

Ondrej Certik ond...@certik.cz writes:

 Plus with git, you can fetch the remote repository with all the
 branches and browse them locally in your remote branches, when you are
 offline. And merge them with your own branches. In mercurial, it seems
 the only way to see what changes are there and which branch and which
 commits I want to merge is to use hg in, but that requires the
 internet connection, so it's basically like svn.

No, no, ... I think you're misunderstanding how the history graph works
in Mercurial. It works like it does in Git -- changesets are in a
parent-child relationship. So if I cloned a repository at changeset T:

  ... --- T

I'm free to make new commits:

  ... --- T --- A --- B

And you can do the same:

  ... --- T --- X --- Y --- Z

I can pull in your changesets without disrupting my own work:

X --- Y --- Z
   /
  ... --- T --- A --- B

Your changesets will be attached to the graph at the point where you
made them, the same for my changesets. I don't have to merge at this
point, instead I can continue with my work even though the repository
has multiple heads (changesets with no childre). So I make C:

X
   /
  ... --- T --- A --- B --- C

I might now decide that I like your X, Y changesets but not Z, so I
merge them Y into my line of work to create D:

X --- Y --- Z
   /   \
  ... --- T ` D
   \ /
A --- B --- C

or I might decide that I don't need your changesets and discard them by
cloning or by the strip command from mq (one or the other):

  hg clone -r C repo repo-with-C
  hg strip X

The result is a repository that has only the history up to C:

  ... --- T --- A --- B --- C

So I think it's nonsense to say that Mercurial is like Subversion here:
you pull in changesets when online and you can make new commits, merge
commits, delete commits while offline.

Git has the advantage that it names these branches in a nice way, and
you can work with these names across the network. The bookmarks
extension for Mercurial is inspired by this and lets you attach local
names to heads in the graph.

 I don't know if mercurial has improved in this lately, but at least
 for me, that's a major problem with mercurial.

There has been no improvement lately since Mercurial has worked like
this all the time :-)

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.


pgp1bdrHZLYl2.pgp
Description: PGP signature
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

Martin Geisler wrote:
 Ondrej Certik ond...@certik.cz writes:

 Plus with git, you can fetch the remote repository with all the
 branches and browse them locally in your remote branches, when you are
 offline. And merge them with your own branches. In mercurial, it seems
 the only way to see what changes are there and which branch and which
 commits I want to merge is to use hg in, but that requires the
 internet connection, so it's basically like svn.

 No, no, ... I think you're misunderstanding how the history graph works
 in Mercurial. It works like it does in Git -- changesets are in a
 parent-child relationship. So if I cloned a repository at changeset T:

   ... --- T

 I'm free to make new commits:

   ... --- T --- A --- B

 And you can do the same:

   ... --- T --- X --- Y --- Z

 I can pull in your changesets without disrupting my own work:

 X --- Y --- Z
/
   ... --- T --- A --- B

 Your changesets will be attached to the graph at the point where you
 made them, the same for my changesets. I don't have to merge at this
 point, instead I can continue with my work even though the repository
 has multiple heads (changesets with no childre). So I make C:

 X
/
   ... --- T --- A --- B --- C

 I might now decide that I like your X, Y changesets but not Z, so I
 merge them Y into my line of work to create D:

 X --- Y --- Z
/   \
   ... --- T ` D
\ /
 A --- B --- C

 or I might decide that I don't need your changesets and discard them by
 cloning or by the strip command from mq (one or the other):

   hg clone -r C repo repo-with-C
   hg strip X

 The result is a repository that has only the history up to C:

   ... --- T --- A --- B --- C

 So I think it's nonsense to say that Mercurial is like Subversion here:
 you pull in changesets when online and you can make new commits, merge
 commits, delete commits while offline.

 Git has the advantage that it names these branches in a nice way, and
 you can work with these names across the network. The bookmarks
 extension for Mercurial is inspired by this and lets you attach local
 names to heads in the graph.

Thanks a lot for this information, that's really useful.

I am still a bit confused about how this works at the UI level, though,
w.r.t one clone/branch. In bzr, there is one branch and at most one
working tree / repository (at least that's how it is used generally). It
looks like hg, while being based on one branch / repository, is a more
flexible. One thing which converted me to git from bzr was the UI for
branch comparison. My basic reference is for release process. Currently,
in numpy, we have the trunk, and potentially several release branches,
which would be one head each if I get the vocabulary right:

   -- A  B --- C (1.2.x head)
 /
trunk -- Release 1.2.0  Release 1.3.0  (mainline head)
   \
 D- E --- F
 (1.3.x head)

How do you refer to different branches from one clone ? For example, if
I want to see the differences between mainline and 1.3.x branch,
cherry-pick things from mainline into both 1.3.x and 1.2.x, etc... How
does it work with bookmarks ?

Also, do we have to agree on everyone using bookmark to communicate each
other (one repository for everything on main numpy web repository), or
can people still use clones for every branch, and putting things back
into bookmarks when they push things in the official repo ?

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Martin Geisler]

David Cournapeau da...@ar.media.kyoto-u.ac.jp writes:

Hi David x 2 :-)

I've put the David Soria on Cc since he wrote the bookmarks extension,
maybe he can give additional information. The thread can be found here:

  http://thread.gmane.org/gmane.comp.python.numeric.general/29117

 Martin Geisler wrote:

 [...] changesets are in a parent-child relationship. So if I cloned a
 repository at changeset T:

   ... --- T

 I'm free to make new commits:

   ... --- T --- A --- B

 And you can do the same:

   ... --- T --- X --- Y --- Z

 I can pull in your changesets without disrupting my own work:

 X --- Y --- Z
/
   ... --- T --- A --- B

 Your changesets will be attached to the graph at the point where you
 made them, the same for my changesets. I don't have to merge at this
 point, instead I can continue with my work even though the repository
 has multiple heads (changesets with no childre). So I make C:

 X
/
   ... --- T --- A --- B --- C

 I might now decide that I like your X, Y changesets but not Z, so I
 merge them Y into my line of work to create D:

 X --- Y --- Z
/   \
   ... --- T ` D
\ /
 A --- B --- C

 or I might decide that I don't need your changesets and discard them by
 cloning or by the strip command from mq (one or the other):

   hg clone -r C repo repo-with-C
   hg strip X

 The result is a repository that has only the history up to C:

   ... --- T --- A --- B --- C

 So I think it's nonsense to say that Mercurial is like Subversion here:
 you pull in changesets when online and you can make new commits, merge
 commits, delete commits while offline.

 Git has the advantage that it names these branches in a nice way, and
 you can work with these names across the network. The bookmarks
 extension for Mercurial is inspired by this and lets you attach local
 names to heads in the graph.

 Thanks a lot for this information, that's really useful.

Great! I trust that you guys will let me know when/if you get tired of
this discussion :-)

 I am still a bit confused about how this works at the UI level,
 though, w.r.t one clone/branch. In bzr, there is one branch and at
 most one working tree / repository (at least that's how it is used
 generally). It looks like hg, while being based on one branch /
 repository, is a more flexible. One thing which converted me to git
 from bzr was the UI for branch comparison. My basic reference is for
 release process. Currently, in numpy, we have the trunk, and
 potentially several release branches, which would be one head each if
 I get the vocabulary right:

 --- A --- B --- C (1.2.x head)
   /
 trunk --- Release 1.2.0 --- Release 1.3.0 --- (mainline head)
  \
D --- E --- F --- (1.3.x head)


 How do you refer to different branches from one clone ? For example,
 if I want to see the differences between mainline and 1.3.x branch,
 cherry-pick things from mainline into both 1.3.x and 1.2.x, etc... How
 does it work with bookmarks ?

You write things like

  hg diff -r F -r tip

where 'tip' is a built-in name that always point to the newest revision
in a repository. If you have a bookmark named 'numpy-1.2.x' on F you
could write:

  hg diff -r numpy-1.2.x -r tip

As for cherry-picking the recommended way (in both Git and Mercurial, as
far as I know) is to do the commit on the oldest relevant branch and
then merge this branch into younger branches and finally into the
mainline. This way each branch is a strict subset of the next branch,
and mainline contains all commits on all branches.

But of course one might realise too late that a changeset on mainline
should have been made on, say, the 1.3.x branch. In case one can apply
the change as a new changeset by exporting it from mainline and
importing it on 1.3.x:

  hg export tip  tip.patch
  hg update -C 1.3.x
  hg import tip.patch

The transplant extension for Mercurial can help with this, probably with
better handling of merges, but I don't have any real experience with it.

 Also, do we have to agree on everyone using bookmark to communicate
 each other (one repository for everything on main numpy web
 repository), or can people still use clones for every branch, and
 putting things back into bookmarks when they push things in the
 official repo ?

The bookmarks is a convenience layer on top of the basic functionality
in Mercurial. They let you attach a name to a changeset just like a tag,
but unlike tags the names move around: if you make a commit based on a
changeset F with 'numpy-1.3.x', the child changeset will now have the
bookmark 'numpy-1.3.x'. This way bookmarks become moveable pointers into
the history, similarly to how Git heads point to changesets in the
history.

At the moment, bookmarks are even local to a repository, but it is
planned to add support for looking them up 

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Mon, Apr 13, 2009 at 6:22 PM, Martin Geisler m...@lazybytes.net wrote:


  hg diff -r F -r tip

 where 'tip' is a built-in name that always point to the newest revision
 in a repository. If you have a bookmark named 'numpy-1.2.x' on F you
 could write:

  hg diff -r numpy-1.2.x -r tip

Ok, so bookmarks are like named branches in that regard. But what if
they happened to be in different repositories ? If you have two
clones, how do you refer one clone from the other ? That's where bzr
UI for branch handling broke IMHO, so I was wondering about hg ?


 As for cherry-picking the recommended way (in both Git and Mercurial, as
 far as I know) is to do the commit on the oldest relevant branch and
 then merge this branch into younger branches and finally into the
 mainline. This way each branch is a strict subset of the next branch,
 and mainline contains all commits on all branches.

 But of course one might realise too late that a changeset on mainline
 should have been made on, say, the 1.3.x branch. In case one can apply
 the change as a new changeset by exporting it from mainline and
 importing it on 1.3.x:

  hg export tip  tip.patch
  hg update -C 1.3.x
  hg import tip.patch

 The transplant extension for Mercurial can help with this, probably with
 better handling of merges, but I don't have any real experience with it.

Ok.


 The bookmarks is a convenience layer on top of the basic functionality
 in Mercurial. They let you attach a name to a changeset just like a tag,
 but unlike tags the names move around: if you make a commit based on a
 changeset F with 'numpy-1.3.x', the child changeset will now have the
 bookmark 'numpy-1.3.x'. This way bookmarks become moveable pointers into
 the history, similarly to how Git heads point to changesets in the
 history.

 At the moment, bookmarks are even local to a repository, but it is
 planned to add support for looking them up remotely and for transferring
 them on push/pull. But right now you cannot tell if I'm using bookmarks
 to keep track of the heads in my clone.

So it means that we would have to keep clones for each branch on the
server at the moment, right ? Can I import this into bookmarks ? Say,
we have three numpy branches on scipy.org:

numpy-mainline
numpy-1.2.x
numpy-1.3.x

and I want to keep everything into one repository, each branch being
bookmark. It looks like it is possible internally from my
understanding on how it works in hg, but does the UI supports it ?

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Martin Geisler]

David Cournapeau courn...@gmail.com writes:

 On Mon, Apr 13, 2009 at 6:22 PM, Martin Geisler m...@lazybytes.net wrote:

  hg diff -r F -r tip

 where 'tip' is a built-in name that always point to the newest
 revision in a repository. If you have a bookmark named 'numpy-1.2.x'
 on F you could write:

  hg diff -r numpy-1.2.x -r tip

 Ok, so bookmarks are like named branches in that regard.

Yeah, sort of. Bookmarks are actually more like tags: both concepts
allow you to give a changeset a friendly name.

Named branches are slightly different: they allow you to stamp a
friendly name on a changeset, but not on just one changeset -- all
changesets in the named branch get the stamp. The branch name can be
used in operations like 'hg update', 'hg diff', etc, and will resolve to
the tip-most changeset on the branch.

 But what if they happened to be in different repositories ? If you
 have two clones, how do you refer one clone from the other ? That's
 where bzr UI for branch handling broke IMHO, so I was wondering about
 hg ?

You're right, the UI is not so good. In particular, you cannot use 'hg
diff' to compare repositories. The rdiff extension does this, though:

  http://www.selenic.com/mercurial/wiki/index.cgi/RdiffExtension

Using stock Mercurial you can use 'hg incoming -p' to see the patches of
the incoming (missing) changesets, or you can pull in the changesets and
then look at them -- if you don't like them you can remove them again.

 At the moment, bookmarks are even local to a repository, but it is
 planned to add support for looking them up remotely and for
 transferring them on push/pull. But right now you cannot tell if I'm
 using bookmarks to keep track of the heads in my clone.

 So it means that we would have to keep clones for each branch on the
 server at the moment, right ?

Yes, that would be easiest. The bookmarks are stored in a plain text
file (.hg/bookmarks) which can be copied around, but the bookmarks will
only update themselves upon commit when they point to a head changeset.

 Can I import this into bookmarks ? Say, we have three numpy branches
 on scipy.org:

 numpy-mainline
 numpy-1.2.x
 numpy-1.3.x

 and I want to keep everything into one repository, each branch being
 bookmark. It looks like it is possible internally from my
 understanding on how it works in hg, but does the UI supports it ?

Right, it is supported -- you would just pull the changesets from each
clone into one clone and this will merge the acyclic graphs into one
graph with all changesets.

You could do this in just your clone, without requiring the numpy server
to do the same. If you do this you'll probably want to attach three
bookmarks in your clone in order to make it easy for yourself to update
From one head to another.

Or you could use named branches for the numpy-1.2.x and numpy-1.3.x
branches -- then everybody would see the branch names when they clone
the combined repository.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.


pgp0Yi7rDaRaA.pgp
Description: PGP signature
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Stéfan van der Walt]

2009/4/12 Stéfan van der Walt ste...@sun.ac.za:
 I underestimated the
 value of this type of manipulation, and of having a clearly structured
 and easily traversable history.

I read that Bram Cohen of Codeville / patience diff fame doesn't
agree with me, so I'll give his opinion too:


Don't bother with a pretty history.

The history of a branch is hardly ever looked at. Making it look
pretty for the historians is just a waste of time. The beauty of 3-way
merge is that you can always clean stuff up later and never worry
about the past mess ever again. In particular, don't go to great
lengths to make sure that there's a coherent local image of the entire
repository exactly as it appeared on your local machine after every
new feature. There are very rare projects which maintain a level of
reliability and testing which warrant such behavior, and yours isn't
one of them.


http://bramcohen.livejournal.com/52148.html

I look at the SciPy history a lot, so I'm not convinced, but there it is.

Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Stéfan van der Walt]

2009/4/12 Fernando Perez fperez@gmail.com:
 What you need to
 accept is that the core objects you should manipulate are the atomic
 change units needed to reconstruct the state of the project, and the
 connectivity between those units.  If you have tools to manipulate
 said entities,  you'll be able to really integrate the work that many
 people may be doing on the same objects in disconnected ways, back
 into a single coherent entity.

Your paragraph above very neatly sums up the conclusion I have been
converging towards during the last couple of months.  Back at Sage
Days 8, when we discussed the different systems, I underestimated the
value of this type of manipulation, and of having a clearly structured
and easily traversable history.

Of course, back then git wasn't even an option, being somewhat crude,
but the playing field has levelled since.  With git, I have discovered
the joys of patch carving (patch manipulation), and contributing
well polished patches to any project, including those you don't have
repository access to, becomes painless.

Thanks for taking the time to write.  It's great to hear from more
experienced DVCS users!

Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Pauli Virtanen]

Fri, 10 Apr 2009 18:50:36 -1000, Eric Firing wrote:
[clip]
 Ah, I think I was confused between named branches and bookmarks. From
 the description of bookmarks, this actually looks nearer to the git
 cheap branch concept. I should really try it to get a good
 understanding, though.
 
 I would not be surprised if bookmarks were directly inspired by that.
 There is also a localbranch extension, but it is not included in the
 distribution and hasn't gotten much attention. I have the sense that
 bookmarks were designed to accomplish the same thing.

Hg bookmarks cannot be easily shared remotely, similarly to Git's 
branches. This is okay for topic branches, but is a drawback if you want 
to share multiple lines of work with other people.

Also, based on a quick try, hg rebase + hg bookmarks don't play 
completely well together, as rebasing tends to move also the trunk 
bookmark around.

-- 
Pauli Virtanen

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sun, Apr 12, 2009 at 12:58 PM, Ondrej Certik ond...@certik.cz wrote:


 I am just surprised, you have exactly the same experience with bzr, I
 thought it's only hg.

I agree that simplicity is a bit overrated. Sure, bzr is simpler than
git - at the beginning. But once you start thinking about shared
repository, stacked branches, checkout, looms (bzr equivalent of
mercurial queues), etc... is it still so simple ? Git is more in your
face, but you don't need much more than that after. I don't think I
use more than 10-12 commands or so.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Martin Geisler]

David Cournapeau courn...@gmail.com writes:

 Ok, will look at it more closely (I have just made a hg repo from the
 numpy git one on my machine). I am still confused about how named
 branches are supposed to work (the hg book is a a bit light on this).
 For example, let's say I want to create a branch from a given
 revision/tag, how should I do it ?

You update to the revision, edit and make a commit. Please see below.

 Since hg branch does not take an -r revision, I tried to create the
 branch first, and then use hg up -r N, but it did not commit as I
 expected from a git perspective:

 hg branch foo
 hg up -r 500
 hg log # show me last revision independently from the branch changes.
 Not so surprising given that the branch was created from the tip of
 default.
 hg ci -m bla
 hg branches # no branch foo ?

 What am I doing wrong ?

As we pointed out to Ondrej Certik on the Mercurial list, 'hg branch' is
very different from 'git branch'. In Mercurial it creates a *named
branch*, which are imbedded in the history and are used for long-term
development branches. Names of Git branches are not recorded in the
history and are thus well-suited for local experiments.

In Mercurial you can create an unnamed branch from any point in the
changeset graph by updating to that point and making a commit:

  hg update 123
  # edit files
  hg commit -m 'My change.'

If you make a commit from a changeset which already has other child
changesets, then you've created an unnamed (anonymous) branch. You can
see this with 'hg heads' -- it shows you the changesets without
children, and having more than one of these means that there are some
unmerged branches.

The bookmarks extension let you assign names to the heads, it is
inspired by the way Git branches work. Unfortunately the bookmarks are
not yet transferred over the network when you do push/pull, but this is
of course a planned feature.

If you want to let others know about a branch you're working on, you can
always put up a separate clone with that branch -- then just delete the
clone if you want to throw away the branch.

If you have multiple heads in a repository, it is easy to separate them
into separate clones:

  hg clone -r some-rev repo repo-with-some-rev

This makes repo-with-some-rev contain some-rev and all ancestor
revisions -- but no other heads. You can merge such splitted clones
again by pulling in changesets from another clone.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.


pgpmpjxg3MCQi.pgp
Description: PGP signature
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Stéfan van der Walt]

Hi Martin

2009/4/13 Martin Geisler m...@lazybytes.net:
 In Mercurial it creates a *named
 branch*, which are imbedded in the history and are used for long-term
 development branches. Names of Git branches are not recorded in the
 history and are thus well-suited for local experiments.

[...]

 The bookmarks extension let you assign names to the heads, it is
 inspired by the way Git branches work. Unfortunately the bookmarks are
 not yet transferred over the network when you do push/pull, but this is
 of course a planned feature.

Thanks for the info.  Maybe you can also help me out with the
following questions: I'd like to know how to duplicate git's branch
workflow in Mercurial.

- How do you create a new head when you are working on top of the
current head?  Do you have to make a dummy commit and then commit on
top of (TIP - 1) whenever you need a new branch?
- Is it possible to remove a head without merging it, discarding the children?

Thanks,
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

Stéfan, or other git-users,

One feature of hg that I use frequently is hg serve, the builtin web 
server.  I use it for two purposes: for temporary local publishing 
(e.g., in place of using ssh--sometimes it is quicker and easier), and 
for providing access to the very nice hgwebdir.cgi browsing capability 
on local repos.  I have looked through git commands etc., and have not 
found an equivalent; am I missing something?  The browsing capability of 
hgwebdir.cgi is much better than any gui interface I have seen for git 
or for hg.  I realize there is a gitweb.cgi, but having that cgi is not 
the same as being able to publish locally with a single command, and 
then browse.

Thanks.

Eric
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Mon, Apr 13, 2009 at 9:26 AM, Eric Firing efir...@hawaii.edu wrote:

 Stéfan, or other git-users,

 One feature of hg that I use frequently is hg serve, the builtin web
 server.  I use it for two purposes: for temporary local publishing
 (e.g., in place of using ssh--sometimes it is quicker and easier), and
 for providing access to the very nice hgwebdir.cgi browsing capability
 on local repos.

There is git daemon, but it does not provide 'web publishing' AFAIK,

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

David Cournapeau wrote:
 On Mon, Apr 13, 2009 at 9:46 AM, David Cournapeau courn...@gmail.com wrote:
 On Mon, Apr 13, 2009 at 9:26 AM, Eric Firing efir...@hawaii.edu wrote:
 Stéfan, or other git-users,

 One feature of hg that I use frequently is hg serve, the builtin web
 server.  I use it for two purposes: for temporary local publishing
 (e.g., in place of using ssh--sometimes it is quicker and easier), and
 for providing access to the very nice hgwebdir.cgi browsing capability
 on local repos.
 There is git daemon, but it does not provide 'web publishing' AFAIK,
 
 But you have this which seems to work (I just checked that gitserve
 gives something which looks like a webpage, nothing more :) ):
 
 http://github.com/jezdez/git-serve/tree/master

Sure enough, that is what I was looking for.  (gitweb doesn't seem to 
have the annotate [or blame, in git-speak] option, or the graph.)
 
 I guess this does not work on windows, though

It probably does--it is written in python.

Thanks.

Eric
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Andrew Straw]

Eric Firing wrote:
 Sure enough, that is what I was looking for.  (gitweb doesn't seem to 
 have the annotate [or blame, in git-speak] option, or the graph.)
   
gitweb does, you have to turn it on, though...
You need to add this to your gitweb.conf, though:

$feature{'blame'}{'default'} = [1];
$feature{'blame'}{'override'} = 1;

I also find pickaxe and snapshot useful:

$feature{'pickaxe'}{'default'} = [1];
$feature{'pickaxe'}{'override'} = 1;

$feature{'snapshot'}{'default'} = ['zip', 'tgz'];
$feature{'snapshot'}{'override'} = 1;

I don't know about the graph. (You mean the gitk --all kind of view? I
saw one JavaScript-y web app that did that, but it was slow and ugly for
any non-trivial repo.)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Sun, Apr 12, 2009 at 7:13 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
 Eric Firing wrote:
 It probably does--it is written in python.


 Yes, but it is just a script to call git-daemon. I am somewhat doubtful
 that it would work on windows, but I would love being proven wrong :)

It uses os.fork() which doesn't work on windows.

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[josef . pktd]

On Sun, Apr 12, 2009 at 10:13 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
 Eric Firing wrote:

 Sure enough, that is what I was looking for.  (gitweb doesn't seem to
 have the annotate [or blame, in git-speak] option, or the graph.)


 It indeed does not support blame, which is a bit of a shame, as git
 blame is so much better than svn blame (it  automatically detects some
 code moves).


 It probably does--it is written in python.


 Yes, but it is just a script to call git-daemon. I am somewhat doubtful
 that it would work on windows, but I would love being proven wrong :)


I looked briefly at the source of gitserve and it's posix only, too
many functions that won't work on windows including fork, and the cgi
script is in perl.

hg serve works well even in my 1 year old mercurial install, however I
didn't find history by subtree which is my favorite in trac, e.g.
http://projects.scipy.org/scipy/log/trunk/scipy/stats

Josef
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Gael Varoquaux]

On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
 On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing efir...@hawaii.edu wrote:
 No need to apologize, I think I used the work bashing inappropriately
 - I just wanted to say that the only way to understand the differences
 between the tools is to use them. Reading about them will only confuse
 you in my own experience. For example, I tried git once a long time
 ago (during an infamous discussion between git and bzr developers on
 the bzr M), could not understand a thing about it, and did not
 understand any point in it except speed. Then I was forced to use git
 because of bzr-svn constant frustrations - and I ended up to really
 like it.

 At last scipy conference, I tried to sell git advantages to Stefan
 (a long time bzr user as well), who was far from convinced from my
 explanations and my ranting. Then later he used it and liked it. Of
 course, the logical conclusion could be that I am just very bad at
 explaining why I like git :)

I am pretty convinced that git is an excellent tool, but it forces people
to invest a fare amount of time to learn it. I struggle quite a lot to
have people use _any_ VCS. I just whish they'd make a usability effort.
They could. There are a lot of low hanging fruits. But they don't care.
It is geeks programming for geeks, not for normal users, IMHO.

Just to make it clear: I could learn git. I wouldn't mind. I just don't
think raising the bar too high to new contributors is good. You have to
start somewhere, and the best way to get new contributors (new in
general, and not only new for scipy) is to make it easy for them.

My 2 cents,

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Gael Varoquaux]

On Fri, Apr 10, 2009 at 11:54:59PM -0600, Charles R Harris wrote:
It seems that designing an intuitive gui that fits a dvcs isn't all that
easy, and git is a bit of a jump because of the way it treats branches and
the irrelevence of time as opposed to change set sequence. I think these
issues will be worked out because dvcs *is* the wave of the future. And
someday numpy will make the switch.

Well said!

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
gael.varoqu...@normalesup.org wrote:
 On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
 On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing efir...@hawaii.edu wrote:
 No need to apologize, I think I used the work bashing inappropriately
 - I just wanted to say that the only way to understand the differences
 between the tools is to use them. Reading about them will only confuse
 you in my own experience. For example, I tried git once a long time
 ago (during an infamous discussion between git and bzr developers on
 the bzr M), could not understand a thing about it, and did not
 understand any point in it except speed. Then I was forced to use git
 because of bzr-svn constant frustrations - and I ended up to really
 like it.

 At last scipy conference, I tried to sell git advantages to Stefan
 (a long time bzr user as well), who was far from convinced from my
 explanations and my ranting. Then later he used it and liked it. Of
 course, the logical conclusion could be that I am just very bad at
 explaining why I like git :)

 I am pretty convinced that git is an excellent tool, but it forces people
 to invest a fare amount of time to learn it. I struggle quite a lot to
 have people use _any_ VCS. I just whish they'd make a usability effort.
 They could. There are a lot of low hanging fruits. But they don't care.
 It is geeks programming for geeks, not for normal users, IMHO.

But that's a development tool. I think it is expected that people have
to somewhat learn something about it. I agree we should care about
barrier of entry - if there is no way to make Josef happy, for
example, that would be a really strong argument against git.

But at the risk of being obvious, we should also care about people who
work on numpy and scipy codebase on a quasi daily basis, no ?

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[josef . pktd]

On Sat, Apr 11, 2009 at 6:38 AM, David Cournapeau courn...@gmail.com wrote:
 On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
 gael.varoqu...@normalesup.org wrote:
 On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
 On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing efir...@hawaii.edu wrote:
 No need to apologize, I think I used the work bashing inappropriately
 - I just wanted to say that the only way to understand the differences
 between the tools is to use them. Reading about them will only confuse
 you in my own experience. For example, I tried git once a long time
 ago (during an infamous discussion between git and bzr developers on
 the bzr M), could not understand a thing about it, and did not
 understand any point in it except speed. Then I was forced to use git
 because of bzr-svn constant frustrations - and I ended up to really
 like it.

 At last scipy conference, I tried to sell git advantages to Stefan
 (a long time bzr user as well), who was far from convinced from my
 explanations and my ranting. Then later he used it and liked it. Of
 course, the logical conclusion could be that I am just very bad at
 explaining why I like git :)

 I am pretty convinced that git is an excellent tool, but it forces people
 to invest a fare amount of time to learn it. I struggle quite a lot to
 have people use _any_ VCS. I just whish they'd make a usability effort.
 They could. There are a lot of low hanging fruits. But they don't care.
 It is geeks programming for geeks, not for normal users, IMHO.

 But that's a development tool. I think it is expected that people have
 to somewhat learn something about it. I agree we should care about
 barrier of entry - if there is no way to make Josef happy, for
 example, that would be a really strong argument against git.

 But at the risk of being obvious, we should also care about people who
 work on numpy and scipy codebase on a quasi daily basis, no ?


David, if your current git svn interface/workflow works well enough
then I think we could move pretty slowly with  switching to a dvcs.

I updated my bzr and hg, with tortoise, (hg I haven't tried yet since
it requires a computer restart)

the svn support in bzr has improved considerably in the last half
year, now bzr-svn uses its own svn bindings instead of pysvn.

I checked out the scikits and scipy svn without errors with bzr.
bzr-svn doesn't get stuck anymore on the end-of-line errors. And
tortoise-bzr and the gui gbzr  are easy to understand and are similar
to svn in the presentation. I expect the new version of hg are the
same, since the hg gui where already ahead last year and tortoise-bzr
is an offspring of tortoise-hg.
What is also very helpful in bzr compared to the git gui, are, for
example, the explanations for different types of checkouts, branches
or repositories are directly build into the windows for
branching/checkout.

mercurials two way support still seems weaker. According to the
hgsubversion webpage the code is not production ready. But, I
haven't tried it out yet.

But if both git and bzr support of local svn branches works well
enough, then it is not so urgent that we switch away from svn. hg
might still require a clearer break since it appears less
interoperable with the other cvs.

windows and gui support for git seems to be improving pretty fast, so
it might be worth the wait.  But the conceptional switch from file
based to patch based interaction seems to be a big jump, that might
always create some dissonance for those of us who think that code is a
collection of files and modules and not a history of changes.

Josef
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Gael Varoquaux]

On Sat, Apr 11, 2009 at 07:38:42PM +0900, David Cournapeau wrote:
 But that's a development tool. I think it is expected that people have
 to somewhat learn something about it. I agree we should care about
 barrier of entry - if there is no way to make Josef happy, for
 example, that would be a really strong argument against git.

I remeber years ago, when I wanted to help out in projects, not
understanding CVS was a big issue, and slowed my involvement by probably
a year at least.

Developping in Python is fairly easy, at least for simple things. We can
coach someone into writing a simple pure-Python numerical algorithm for
scipy, and teach him tests and coding convention. It would be a pitty if
the workflow made it hard. You have spent a huge amount of time improving
the build system. That's an important part. The VCS is another. The
easiest it is for a grad student to download the development version of
scipy, build it, and do small modifications to it, propagated upstream,
the better it is for the project. And remember, most people are never
taught version control.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Bruce Southey]

On Sat, Apr 11, 2009 at 5:38 AM, David Cournapeau courn...@gmail.com wrote:
 On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
 gael.varoqu...@normalesup.org wrote:
 On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
 On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing efir...@hawaii.edu wrote:
 No need to apologize, I think I used the work bashing inappropriately
 - I just wanted to say that the only way to understand the differences
 between the tools is to use them. Reading about them will only confuse
 you in my own experience. For example, I tried git once a long time
 ago (during an infamous discussion between git and bzr developers on
 the bzr M), could not understand a thing about it, and did not
 understand any point in it except speed. Then I was forced to use git
 because of bzr-svn constant frustrations - and I ended up to really
 like it.

 At last scipy conference, I tried to sell git advantages to Stefan
 (a long time bzr user as well), who was far from convinced from my
 explanations and my ranting. Then later he used it and liked it. Of
 course, the logical conclusion could be that I am just very bad at
 explaining why I like git :)

 I am pretty convinced that git is an excellent tool, but it forces people
 to invest a fare amount of time to learn it. I struggle quite a lot to
 have people use _any_ VCS. I just whish they'd make a usability effort.
 They could. There are a lot of low hanging fruits. But they don't care.
 It is geeks programming for geeks, not for normal users, IMHO.

 But that's a development tool. I think it is expected that people have
 to somewhat learn something about it. I agree we should care about
 barrier of entry - if there is no way to make Josef happy, for
 example, that would be a really strong argument against git.

How good is the conversion between git, bzr and hg?
Rather can the selected system sufficiently support the other systems?


 But at the risk of being obvious, we should also care about people who
 work on numpy and scipy codebase on a quasi daily basis, no ?


There are at least two components:
1) Developers
2) Users like myself that test and use developmental versions and
provide the odd error report and patch.

Under the distributed approach, a developmental version does not
exist. Is there going to be a way to address this or will we have to
wait to release candidates to appears? Also, comments like 'get the
latest version from the trunk' does become rather meaningless.

Bruce
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sun, Apr 12, 2009 at 12:05 AM, Bruce Southey bsout...@gmail.com wrote:
 On Sat, Apr 11, 2009 at 5:38 AM, David Cournapeau courn...@gmail.com wrote:
 On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
 gael.varoqu...@normalesup.org wrote:
 On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
 On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing efir...@hawaii.edu wrote:
 No need to apologize, I think I used the work bashing inappropriately
 - I just wanted to say that the only way to understand the differences
 between the tools is to use them. Reading about them will only confuse
 you in my own experience. For example, I tried git once a long time
 ago (during an infamous discussion between git and bzr developers on
 the bzr M), could not understand a thing about it, and did not
 understand any point in it except speed. Then I was forced to use git
 because of bzr-svn constant frustrations - and I ended up to really
 like it.

 At last scipy conference, I tried to sell git advantages to Stefan
 (a long time bzr user as well), who was far from convinced from my
 explanations and my ranting. Then later he used it and liked it. Of
 course, the logical conclusion could be that I am just very bad at
 explaining why I like git :)

 I am pretty convinced that git is an excellent tool, but it forces people
 to invest a fare amount of time to learn it. I struggle quite a lot to
 have people use _any_ VCS. I just whish they'd make a usability effort.
 They could. There are a lot of low hanging fruits. But they don't care.
 It is geeks programming for geeks, not for normal users, IMHO.

 But that's a development tool. I think it is expected that people have
 to somewhat learn something about it. I agree we should care about
 barrier of entry - if there is no way to make Josef happy, for
 example, that would be a really strong argument against git.

 How good is the conversion between git, bzr and hg?

git - bzr works well for one time import, because they share a
common stream format for exchange. I don't know for hg (there is
hg-git, but I don't know the other direction - I used the convert
extension to try hg named branches from my git import of numpy).

 Rather can the selected system sufficiently support the other systems?

I think it would only lead to more complication, weird errors and
confusion. I know at least gnome thought about this, and quickly gave
up.

 There are at least two components:
 1) Developers
 2) Users like myself that test and use developmental versions and
 provide the odd error report and patch.

 Under the distributed approach, a developmental version does not
 exist.

It is exactly the same as before - there is a reference branch for
main development that people would use.

 Also, comments like 'get the
 latest version from the trunk' does become rather meaningless.

It is meaningless because there is nothing to do :) If you look at the
actual git mirror

http://projects.scipy.org/git/?p=numpy;a=summary

The snapshot link gives you a tarball for every revision (this is not
specific to git, at least hg web portal has the same capability).

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Sat, Apr 11, 2009 at 11:44 AM, Neal Becker ndbeck...@gmail.com wrote:
 Ondrej Certik wrote:

 On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing efir...@hawaii.edu wrote:
 Ondrej Certik wrote:
 On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
 da...@ar.media.kyoto-u.ac.jp wrote:
 Ondrej Certik wrote:
 It is maybe easier to learn how to work with different clones, but
 once you start working with lots of patches and you need to reclone
 all the time, then it's the wrong approach to work, as it takes lots
 of time to copy the whole repository on the disk.

 This is simply wrong.  Mercurial uses hard links for cloning a repo that

 On my laptop, recloning the whole repository (with hardlinks) takes
 considerably longer than creating a new branch in the same directory,
 that's a pure fact.

 You can clone a repo using:
 cp -al old new

 That should be very fast.

 As long as you then use an editor that behaves correctly with hard links.
 If you use emacs you can configure this behavior.

Ok, this seems to be pretty fast:

$ time cp -al sympy-git.hg/ new

real0m0.129s
user0m0.020s
sys 0m0.084s


e.g. this was the mercurial repo.

Creating a new branch in git:

$ time git co -b new2
Switched to a new branch new

real0m0.048s
user0m0.020s
sys 0m0.016s


is faster, but I agree, that 0.1s is not an issue for me. Is this
going to work on windows? I thought windows don't have hardlinks.
In any case, I would prefer to use standard mercurial tools for the
job, so if I do:

$ time hg clone sympy-git.hg new
updating working directory
566 files updated, 0 files merged, 0 files removed, 0 files unresolved

real0m1.156s
user0m0.948s
sys 0m0.164s


it still takes over a second. That's too much for me, as this
operation of creating new branches is something that I do almost all
the time.

The way out is to use branches in on repository, and imho that's the
correct way, both in git and in mercurial.

However, is here anyone who actually uses branches in mercurial? If
so, try this:

hg clone http://hg.sympy.org/sympy-git.hg
cd sympy-git.hg
hg branch new2
vim README  # do some changes
hg ci
hg up -C default
hg vi

and the hg vi doesn't even show your branch names and which branch
contains what.

let's edit README in the default branch:

vim README
hg ci

now if you do:

hg vi

it shows the new2 branch, and it shows the main branch diverged, so it
doesn't look as nice as in gitk, but it is possible to use. Now let's
try mercurial rebase:

$ hg up -C new2
$ hg rebase -d default
merging README
saving bundle to /tmp/ab/hg/sympy-git.hg/.hg/strip-backup/536215160a1c-temp
adding branch
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files
abort: 00changelo...@536215160a1c: no node!


Oops, something went wrong. But commits are still there, so I guess I
can safely ignore the error message (could someone clarify?).

Now let's say I would like to merge the top two patches, since they
both modify readme and I would like to only send one patch. In git, I
just do git rebase -i HEAD~2 tell it in vim which patches to squash
and I am done. In mercurial, it's a hell of a job:

$ hg qimport -r tip
$ hg qimport -r qparent
$ hg qpop
now at: 2146.diff
$ hg qfold 2147.diff
$ hg qdelete -r qbase:qtip

And I am still not done! I forgot to change the log (git asks you this
automatically during the rebase), so we need to import the patch to MQ
again:

$ hg qimport -r tip
$ hg qrefresh -e
$ hg qdelete -r qbase:qtip


And I am finally done. Now let's say some of the patches in MQ didn't
apply after changing the order or some other changes. Then I am in
deep troubles, because hg qpush fails and I need to modify the patch
by hand (that really sucks!). With git, you only use rebase, and
rebase is pretty powerful tool that can handle most of the conflicts
itself, and if it can't, it asks you to resolve it, I assume just like
mercurial rebase, but unfortunately mercurial rebase can't be used to
mangle patches or history.

I would like to ask mercurial proponents on this list to please
correct me above and do it the right way. :) So that it's not biased.

Also, read this nice article, that imho nicely compares git and mercurial:

http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Neal Becker]

Ondrej Certik wrote:

 On Sat, Apr 11, 2009 at 11:44 AM, Neal Becker ndbeck...@gmail.com wrote:
 Ondrej Certik wrote:

 On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing efir...@hawaii.edu
 wrote:
 Ondrej Certik wrote:
 On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
 da...@ar.media.kyoto-u.ac.jp wrote:
 Ondrej Certik wrote:
 It is maybe easier to learn how to work with different clones, but
 once you start working with lots of patches and you need to reclone
 all the time, then it's the wrong approach to work, as it takes lots
 of time to copy the whole repository on the disk.

 This is simply wrong.  Mercurial uses hard links for cloning a repo
 that

 On my laptop, recloning the whole repository (with hardlinks) takes
 considerably longer than creating a new branch in the same directory,
 that's a pure fact.

 You can clone a repo using:
 cp -al old new

 That should be very fast.

 As long as you then use an editor that behaves correctly with hard links.
 If you use emacs you can configure this behavior.
 
 Ok, this seems to be pretty fast:
 
 $ time cp -al sympy-git.hg/ new
 
 real  0m0.129s
 user  0m0.020s
 sys   0m0.084s
 
 
 e.g. this was the mercurial repo.
 
 Creating a new branch in git:
 
 $ time git co -b new2
 Switched to a new branch new
 
 real  0m0.048s
 user  0m0.020s
 sys   0m0.016s
 
 
 is faster, but I agree, that 0.1s is not an issue for me. Is this
 going to work on windows? I thought windows don't have hardlinks.
 In any case, I would prefer to use standard mercurial tools for the
 job, so if I do:
 
 $ time hg clone sympy-git.hg new
 updating working directory
 566 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
 real  0m1.156s
 user  0m0.948s
 sys   0m0.164s
 
 
 it still takes over a second. That's too much for me, as this
 operation of creating new branches is something that I do almost all
 the time.
 
 The way out is to use branches in on repository, and imho that's the
 correct way, both in git and in mercurial.
 
 However, is here anyone who actually uses branches in mercurial? If
 so, try this:
 
 hg clone http://hg.sympy.org/sympy-git.hg
 cd sympy-git.hg
 hg branch new2
 vim README  # do some changes
 hg ci
 hg up -C default
 hg vi
 
 and the hg vi doesn't even show your branch names and which branch
 contains what.
 
 let's edit README in the default branch:
 
 vim README
 hg ci
 
 now if you do:
 
 hg vi
 
 it shows the new2 branch, and it shows the main branch diverged, so it
 doesn't look as nice as in gitk, but it is possible to use. Now let's
 try mercurial rebase:
 
 $ hg up -C new2
 $ hg rebase -d default
 merging README
 saving bundle to
 /tmp/ab/hg/sympy-git.hg/.hg/strip-backup/536215160a1c-temp adding branch
 adding changesets
 adding manifests
 adding file changes
 added 2 changesets with 2 changes to 1 files
 abort: 00changelo...@536215160a1c: no node!
 
 
 Oops, something went wrong. But commits are still there, so I guess I
 can safely ignore the error message (could someone clarify?).
 
 Now let's say I would like to merge the top two patches, since they
 both modify readme and I would like to only send one patch. In git, I
 just do git rebase -i HEAD~2 tell it in vim which patches to squash
 and I am done. In mercurial, it's a hell of a job:
 
 $ hg qimport -r tip
 $ hg qimport -r qparent
 $ hg qpop
 now at: 2146.diff
 $ hg qfold 2147.diff
 $ hg qdelete -r qbase:qtip
 
 And I am still not done! I forgot to change the log (git asks you this
 automatically during the rebase), so we need to import the patch to MQ
 again:
 
 $ hg qimport -r tip
 $ hg qrefresh -e
 $ hg qdelete -r qbase:qtip
 
 
 And I am finally done. Now let's say some of the patches in MQ didn't
 apply after changing the order or some other changes. Then I am in
 deep troubles, because hg qpush fails and I need to modify the patch
 by hand (that really sucks!). With git, you only use rebase, and
 rebase is pretty powerful tool that can handle most of the conflicts
 itself, and if it can't, it asks you to resolve it, I assume just like
 mercurial rebase, but unfortunately mercurial rebase can't be used to
 mangle patches or history.
 
 I would like to ask mercurial proponents on this list to please
 correct me above and do it the right way. :) So that it's not biased.
 
 Also, read this nice article, that imho nicely compares git and mercurial:
 
 http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/
 

Why not try asking on mercur...@selenic.com (gmane.comp.version-
control.mercurial.general)


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Sat, Apr 11, 2009 at 2:12 PM, Neal Becker ndbeck...@gmail.com wrote:

 Why not try asking on mercur...@selenic.com (gmane.comp.version-
 control.mercurial.general)

Done:

http://www.selenic.com/pipermail/mercurial/2009-April/025131.html

O.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Stéfan van der Walt]

Hi all,

DVCS discussions are notoriously unproductive, aren't they :)

The two systems under discussion, git and hg, are both *almost* what
we want, which means we have to make a choice and compromise.


Here are some of the pros and cons I've picked up, and I'm sure you
can add more:

Git has well-integrated in-place branches, allows you to easily do
patch carving (i.e. manipulation of patches to get them Just Right
(TM)) and is very fast.  Mercurial has a more intuitive interface /
less confusing error messages in places, has a very good http serving
protocol, is written in and used by Python.  Bzr wasn't included in
the discussion, but its patience diff algorithm and good user
interface is worth mentioning.


We have to decide which of these attributes are more important to the
developers and users of NumPy and SciPy, and then go with that system.

Alternatively, we can simply ignore the arguments and pick one
randomly.  Having any DVCS in place would improve the situation and,
besides, it's easy to switch to another system later if we make an
enormous error in judgement.

Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Charles R Harris]

2009/4/11 Stéfan van der Walt ste...@sun.ac.za

 Hi all,

 DVCS discussions are notoriously unproductive, aren't they :)

 The two systems under discussion, git and hg, are both *almost* what
 we want, which means we have to make a choice and compromise.


 Here are some of the pros and cons I've picked up, and I'm sure you
 can add more:

 Git has well-integrated in-place branches, allows you to easily do
 patch carving (i.e. manipulation of patches to get them Just Right
 (TM)) and is very fast.  Mercurial has a more intuitive interface /
 less confusing error messages in places, has a very good http serving
 protocol, is written in and used by Python.  Bzr wasn't included in
 the discussion, but its patience diff algorithm and good user
 interface is worth mentioning.


 We have to decide which of these attributes are more important to the
 developers and users of NumPy and SciPy, and then go with that system.

 Alternatively, we can simply ignore the arguments and pick one
 randomly.  Having any DVCS in place would improve the situation and,
 besides, it's easy to switch to another system later if we make an
 enormous error in judgement.


I vote that we don't even think about a decision until next year. The
current system works well enough, I think. Meanwhile, the endless
discussions are fun and pass the time.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Stéfan van der Walt]

2009/4/12 Charles R Harris charlesr.har...@gmail.com:
 I vote that we don't even think about a decision until next year. The
 current system works well enough, I think. Meanwhile, the endless
 discussions are fun and pass the time.

I'll take that with a pinch of salt, as I assume it was intended :)

From my POV, the current system is very unproductive and, while
git-svn makes life a bit easier, it comes with its own set of
headaches.  Especially now that we are evaluating different
work-flows, we need the right kind of vcs to back it up.

Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Fernando Perez]

2009/4/11 Stéfan van der Walt ste...@sun.ac.za:

 From my POV, the current system is very unproductive and, while
 git-svn makes life a bit easier, it comes with its own set of
 headaches.  Especially now that we are evaluating different
 work-flows, we need the right kind of vcs to back it up.

Please take the following with a big grain of salt, because I haven't
used either git nor hg beyond trivial cloning.  But I do have by now
pretty extensive experience with bzr (ipython and nipy), so I think
I've developed a decent intuition on what's important/useful in the
long run from DVCS workflows.  I have also been reading a fair amount
about git and hg, in particular about the core of their internal
models.  This, it seems to me, is actually far more important in the
long run than their top-layer polish.

From that perspective, right now my intuition (and yes, it's only that
for now) tells me that git has some really appealing features for a
dvcs, which as far as I can see are not present in hg (seeing as
unless I've grossly misunderstood it, it is much closer to bzr in its
internal model than to git).  To me the key point in git of
fundamental value is its direct manipulation of the commit DAG and
history: this is something that I think one only comes to appreciate
after using a DVCS for *a reasonably long time* on a *reasonably
complex project* with multiple developers, branches and merges.  I
stress this because I think these points really only become apparent
under such conditions, at least I didn't really think of these things
until I used bzr extensively for ipython.

Let me elaborate a bit.  One of the main benefits of a DVCS is that it
enables all developers to be aggressive locally, to experiment on
crazy ideas and to use the VCS as their safety line in their
experimentation.  You are free to try crazy things, commit as often
and finely-grained as you want, and if things go wrong, you can
backtrack easily.  But in general what happens is that things don't
simply go wrong: you often end up making things work, it's just that
the intermediate history can look totally crazy, with tons of
intermediate commits that are really of no interest anymore to anyone.
 With git, there is a way of saying merge all this into a single
commit (or a few) so that it goes into the upstream project into
chunks that make logical sense and not just that reflect your
tiptoeing during a tricky part of the development.

In bzr (and as far as I see, also in hg),  this kind of history
rewriting is near impossible, so the best you can do is make a merge
commit and leave all that history in there, visible in the 'second
level' log (indented in the text view).  As a project grows many
developers, having all this history merged back into the main project
tree gets unwieldy.

From my (now reasonably extensive) experience with bzr, it really
feels like a system that took the centralized VCS model and put 'a
little svn server everywhere you need one'.  That is, the
repository/branch/history model retains the rigidity of a centralized
VCS, it's just that you can have it anywhere, and it can track
branching and merging intelligently.  There's certainly a lot of value
in that, I am not denying it in the least bit.

However,  git seems to really make the key conceptual jump of saying:
once you have a truly distributed development process, that rigid
model just breaks down and should be abandoned.  What you need to
accept is that the core objects you should manipulate are the atomic
change units needed to reconstruct the state of the project, and the
connectivity between those units.  If you have tools to manipulate
said entities,  you'll be able to really integrate the work that many
people may be doing on the same objects in disconnected ways, back
into a single coherent entity.

Sorry if this seems a bit in the air, but I've been thinking about
this for the past couple of days, and I figured I'd share.  I don't
mean this to be a bashing of hg or bzr (which we'll continue using for
ipython at least for a long while, since now is not the time for yet
another workflow change for us).  But from *my* perspective, git
offers really the correct abstractions to think about distributed
collaborative workflows, while the other systems simply seem to offer
tools to distribute the workflow of a rigid development history (a la
CVS) to multiple developers. There's a fundamental difference between
thosee two approaches, and I think it's a critically important one.

As for what numpy/scipy should do, I'll leave that to those who
actually contribute to the projects :)  I just hope that this view is
useful to anyone who wants to think about the problem from an angle
different to that of specific commands, benchmarks or features :)

All the best,

f
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Sat, Apr 11, 2009 at 8:28 PM, Fernando Perez fperez@gmail.com wrote:
 In bzr (and as far as I see, also in hg),  this kind of history
 rewriting is near impossible, so the best you can do is make a merge
 commit and leave all that history in there, visible in the 'second
 level' log (indented in the text view).  As a project grows many
 developers, having all this history merged back into the main project
 tree gets unwieldy.

Great email. Exactly, that's my experience with hg, it makes it nearly
impossible, without misusing mercurial queues.

I am just surprised, you have exactly the same experience with bzr, I
thought it's only hg.

As an amusing story, my roommate here at UNR also switched from svn to
hg and was telling me, you know, git is too unfriendly, hg does
everything I ever need. I was telling myself, well, after you really
start using it, you'll maybe switch to git. Then after couple months
he once told me -- I had to rewrite history, so I tried MQ and that's
a disaster, the interface to it is horrible. So I switched to git.

I was thinking about Fernando just yesterday, asking myself, hm, I
wonder how he is satisfied with bzr. So this email really made me
laugh. :)

 As for what numpy/scipy should do, I'll leave that to those who
 actually contribute to the projects :)  I just hope that this view is

Exactly, this decision should be done by numpy developers, not me either.

 useful to anyone who wants to think about the problem from an angle
 different to that of specific commands, benchmarks or features :)

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

Ondrej Certik wrote:

 It is maybe easier to learn how to work with different clones, but
 once you start working with lots of patches and you need to reclone
 all the time, then it's the wrong approach to work, as it takes lots
 of time to copy the whole repository on the disk.

Yes, *I* know how to use git, and I agree with you, I vastly prefer git
branch handling to bzr branch handling. *I* find working with GUI for
VCS a real PITA. But I am not the only numpy developer, that's why the
feedback from people like Josef with a totally different workflow than
me is valuable - much more than people like us who are unix geeks :)

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
 Ondrej Certik wrote:

 It is maybe easier to learn how to work with different clones, but
 once you start working with lots of patches and you need to reclone
 all the time, then it's the wrong approach to work, as it takes lots
 of time to copy the whole repository on the disk.

 Yes, *I* know how to use git, and I agree with you, I vastly prefer git
 branch handling to bzr branch handling. *I* find working with GUI for
 VCS a real PITA. But I am not the only numpy developer, that's why the
 feedback from people like Josef with a totally different workflow than
 me is valuable - much more than people like us who are unix geeks :)

Yes, definitely.

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

Ondrej Certik wrote:
 On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
 da...@ar.media.kyoto-u.ac.jp wrote:
 Ondrej Certik wrote:
 It is maybe easier to learn how to work with different clones, but
 once you start working with lots of patches and you need to reclone
 all the time, then it's the wrong approach to work, as it takes lots
 of time to copy the whole repository on the disk.

This is simply wrong.  Mercurial uses hard links for cloning a repo that 
is on the same disk, so it is faster and much more space-efficient than 
copying the files. But if you do want named branches in a given repo, 
you can have that also with hg.  Granted, it has not always been part of 
hg, but it is now.  Same with rebasing and transplanting.

Now, I know that your (speaking to Ondrej) project switched from hg to 
git, and you have provided some useful insight as to why.  I also 
understand that there are substantive differences between the two, with 
advantages and disadvantages. But I don't think it follows that numpy 
(or matplotlib, eventually, I hope) necessarily should move to git 
if/when a move to a DVCS is decided upon.  It is possible that hg might 
be a better fit--a better compromise--for present *and* *potential* 
*future* contributors to numpy, scipy, and matplotlib.

 Yes, *I* know how to use git, and I agree with you, I vastly prefer git
 branch handling to bzr branch handling. *I* find working with GUI for
 VCS a real PITA. But I am not the only numpy developer, that's why the
 feedback from people like Josef with a totally different workflow than
 me is valuable - much more than people like us who are unix geeks :)
 

Speaking to David: is git branch handling vastly preferable to both of 
the branch styles available in hg?

Speaking to Josef: does tortoise-hg provide a satisfactory windows gui, 
from your standpoint?

Eric

 Yes, definitely.
 
 Ondrej
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

Eric Firing wrote:

 This is simply wrong.  Mercurial uses hard links for cloning a repo that 
 is on the same disk, so it is faster and much more space-efficient than 
 copying the files.

Yes, but maybe Ondrej talks about an older hg version ? Hg could not
handle NTFS hardlink for some time, but it does now if you have pywin32.

And still, switching between branches is faster in git than in hg, for
some technical reasons I can't really explain (but can be found on the
ML archives). But as I said previously, speed is not really an argument
for me. If hg is fast enough for python, it is obviously fast enough for
numpy and scipy. As long as it does not takes minutes to merge/review
the 5 lines difference between two branches as is the case in svn right
now, I am happier :)

  But if you do want named branches in a given repo, 
 you can have that also with hg.  Granted, it has not always been part of 
 hg, but it is now.  Same with rebasing and transplanting.
   

As I understand, and correct me if I am wrong, the problems with named
branches are:
- you can't remove them later, it is in the repository 'forever'
- it is not easy to make them publicly available

One big potential with the way git does branching is review - gerrit
(the code review tool used by Google for android) looks really nice.
Unfortunately, to see whether this is indeed true requires trying it,
because git-svn cannot be used to that effect (because of branches).

What would be great is to have git-svnserver, like git-cvsserver (which
is a gateway for cvs, that is people who don't want to bother can use
cvs to do as they do normally, and other people can use git proper). I
find it surprising that such a tool does not exist.

 It is possible that hg might 
 be a better fit--a better compromise--for present *and* *potential* 
 *future* contributors to numpy, scipy, and matplotlib.
   

Yes, that may be the case.

 Speaking to David: is git branch handling vastly preferable to both of 
 the branch styles available in hg?
   

Besides git, I am mostly familiar with bzr, which has the branch is a
different directory concept (but no named branches). I think bzr is
very confusing for advanced workflows in relation to this UI (I am too
lazy to restate my reasons, see here:
http://cournape.wordpress.com/2008/10/30/going-away-from-bzr-toward-git).

When I tried hg (version 0.8 maybe ?), there was little support for
named branches, but this has changed since I believe. When you have
different repositories for different branches, comparisons between
branches are difficult. This was the case in bzr. Is this the case in hg
? For example, can you log a subdirectory between two branches, easily
review files changes between branches/tags/etc... For the release
process, I find this very useful - but this can be somewhat alleviated
with git-svn without forcing anyone using it.

If people think that at least trying hg should be possible, I think it
should not be too difficult to have a hg mirror of svn - but I am not
sure whether you can use it to commit back to svn, like git-svn.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Fri, Apr 10, 2009 at 1:07 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
 Eric Firing wrote:

 This is simply wrong.  Mercurial uses hard links for cloning a repo that
 is on the same disk, so it is faster and much more space-efficient than
 copying the files.

 Yes, but maybe Ondrej talks about an older hg version ? Hg could not
 handle NTFS hardlink for some time, but it does now if you have pywin32.

 And still, switching between branches is faster in git than in hg, for
 some technical reasons I can't really explain (but can be found on the
 ML archives). But as I said previously, speed is not really an argument
 for me. If hg is fast enough for python, it is obviously fast enough for
 numpy and scipy. As long as it does not takes minutes to merge/review
 the 5 lines difference between two branches as is the case in svn right
 now, I am happier :)

  But if you do want named branches in a given repo,
 you can have that also with hg.  Granted, it has not always been part of
 hg, but it is now.  Same with rebasing and transplanting.


 As I understand, and correct me if I am wrong, the problems with named
 branches are:
    - you can't remove them later, it is in the repository 'forever'
    - it is not easy to make them publicly available

Plus with git, you can fetch the remote repository with all the
branches and browse them locally in your remote branches, when you are
offline. And merge them with your own branches. In mercurial, it seems
the only way to see what changes are there and which branch and which
commits I want to merge is to use hg in, but that requires the
internet connection, so it's basically like svn. I don't know if
mercurial has improved in this lately, but at least for me, that's a
major problem with mercurial.

But since python now moved to mercurial too, maybe they will help fix this. :)

It seems to me like the python distutils vs cmake discussion. I also
prefer the unpythonic cmake.

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

Eric Firing wrote:
 Speaking to Josef: does tortoise-hg provide a satisfactory windows gui, 
 from your standpoint?
   

Another solution may be eclipse integration. I don't know if that would
work for Josef, but there is a git plugin for eclipse, and I can at
least clone branches from a remote repository, and work with it.

Is there a hg eclipse plugin ? I am not very knowledgeable about IDE,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[josef . pktd]

On Fri, Apr 10, 2009 at 5:13 AM, Matthieu Brucher
matthieu.bruc...@gmail.com wrote:
 2009/4/10 David Cournapeau da...@ar.media.kyoto-u.ac.jp:
 Eric Firing wrote:
 Speaking to Josef: does tortoise-hg provide a satisfactory windows gui,
 from your standpoint?


 Another solution may be eclipse integration. I don't know if that would
 work for Josef, but there is a git plugin for eclipse, and I can at
 least clone branches from a remote repository, and work with it.

 Is there a hg eclipse plugin ? I am not very knowledgeable about IDE,

 Yes, there is MercurialEclipse. I don't know how it handles branches.
 I use BzrEclipse for my work, and it doesn't handle branches at all,
 you have to fall back to the command line.


I tried out mercurial one year ago, including the eclipse plugin, but
it didn't work very well compared to the svn plugin. And since at that
time mercurial to svn connection wasn't very good, I gave up (I have
all my work in svn). I haven't used it since except for checking out
some repositories. It's time consuming to keep track of 4 different
version control systems, and for my main use, I'm quite ok with svn
and minimal use of bzr. I never tried tortoise, because I prefer
standalone programs or program plugins that don't mess with my windows
installation or registry, if I'm not sure I use it long-term.

Now that I see the differences in the branching concept between git
and the other ones, I can understand that for reviewing patches, the
git way of branches in the same directory is much faster.  But how do
you actually run the programs in python? How does python know which
version to access? Or does git change the content of the files
whenever you switch a branch?
Answering my own question, for the record, after some more playing:
`git checkout branchname` changes files in directory to the branch
version, updates changed time stamp to date of checkout (i.e.
modification time of a file in git is useless information).

I think there is a difference in the usage pattern for development and
for reviewing patches. When writing or rewriting code, I just need a
few stable branches (clones) and directory access and information
based on file structure is more convenient, which is also more
consistent with the workspace concept of eclipse.
For reviewing and trying out patches, the patch orientation of git is
more useful, I imagine.

I haven't tried ssh with git yet, with bzr and launchpad, half a year
ago it took several hours of trial and error and googling to get it
setup, (that was quite a few versions of bzr ago).  With svn,
authorization to commit to the scipy repository required filling out
name and password in the svn gui and it worked.

Josef
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

Hi Josef,

josef.p...@gmail.com wrote:

 I tried out mercurial one year ago, including the eclipse plugin, but
 it didn't work very well compared to the svn plugin. And since at that
 time mercurial to svn connection wasn't very good, I gave up (I have
 all my work in svn). I haven't used it since except for checking out
 some repositories. It's time consuming to keep track of 4 different
 version control systems, and for my main use, I'm quite ok with svn
 and minimal use of bzr. I never tried tortoise, because I prefer
 standalone programs or program plugins that don't mess with my windows
 installation or registry, if I'm not sure I use it long-term.
   

(I am trying different tools, in particular tortoisesvn, and eclipse on
windows, to get a 'feeling' of your workflow, and how that can work out
- or not - for git/hg. I will update the wiki accordingly).

 Now that I see the differences in the branching concept between git
 and the other ones, I can understand that for reviewing patches, the
 git way of branches in the same directory is much faster.  But how do
 you actually run the programs in python? How does python know which
 version to access? Or does git change the content of the files
 whenever you switch a branch?
   

Yes. That's what checkout is about in git (git checkout is somewhat
equivalent to svn switch - also again, the comparison breaks quickly
because svn switch can be used to switch repositories and or branches,
which does not make sense in git).

For example, to give you a feeling about why I enjoy git very much:

# add branch published by Josef somewhere for review
git remote add stats_branch url_from_josef_useful_stats
# give me all the changes between the master branch (trunk) and your branch
git diff master..stats_branch scipy/stats
# I want to build your changes, so I create a locate branch which tracks
your branch
git branch local_stats stats_branch/master
# Now I 'checkout' the branch, which means updating the working tree
(the files) from the local_stats branch
git co local_stats  build it
# I do some modification to your branch, maybe - I then see a bug in
scipy stats independent of your changes
git stash # put away all the changes in a stash
# Fix the bug
hack
# Return to your changes, checkout the branch, and revert the changes I
was working on previously
git co local_stats
git stash pop

For the release process, something I have used a lot for numpy 1.3.0
through git-svn (if using git, it would be easier, git-svn can be quirky)

# Log for the last few days
git log --since='one week'
# Get an idea of the modified files in the 1.3.x branch: number of lines
modified/file
git diff --stat svn/branches/1.3.x
# Review changes between the beta and the rc
git diff 1.3.0b1..1.3.0rc1
git log 1.3.0b1..1.3.0rc1
# Something fails building in the rc1, or maybe some tests - check that
the beta did not have this problem by rebuilding
# from scratch
git co 1.3.0b1  make test_scratch

All this is excruciating on svn. Switching branches is not reliable, and
takes ages (it is of the order of minutes for every single command).
Diffing/log of branches is even worse, and the command line UI is really
painful (I can't understand why I have to use full URL for branches in svn).

One problem which does not concern many people, but which is quite acute
at least for me: I often need to check some changes on several platforms
at the same time (windows/linux, generally). With svn, I have no choice
but to commit every change to svn, and svn acts as the gateway - making
my own local gateway is just too much work. With git, that's relatively
easy (but bzr is easier - that's one thing I really miss from bzr), I
can just make sure everything work instead of making tons of useless and
broken commits.

 Answering my own question, for the record, after some more playing:
 `git checkout branchname` changes files in directory to the branch
 version, updates changed time stamp to date of checkout (i.e.
 modification time of a file in git is useless information)
   

Yes, git tracks content (that is the whole tree). I did not think about
this, because I never use this information even on svn - I use the
command line. You have to use GUI to notice this problem :)

 I haven't tried ssh with git yet, with bzr and launchpad, half a year
 ago it took several hours of trial and error and googling to get it
 setup, (that was quite a few versions of bzr ago).  With svn,
 authorization to commit to the scipy repository required filling out
 name and password in the svn gui and it worked.
   

Yes, this would take some time (from people involved in the eventual
transition) to get right. Launchpad was not very good at it. But this is
independent of the DVCS: either bzr, hg or git would need to use a
ssh-based mechanism I think (so the good news is that you have already
done all the work for launchpad :) ).

cheers,

David
___
Numpy-discussion mailing list

Re: [Numpy-discussion] DVCS at PyCon

[Christopher Barker]

David Cournapeau wrote:
 we're really better off with a system with
 good tool support on all platforms.
 
 Why ? We are not python, where many core developers work on windows.

As I understand it there is a dearth of Python developers on Windows, 
too... But anyway, we probably want MORE Windows folks contributing, not 
fewer.

Another key is the core developers concept -- I'm not a core developer 
on any major OS project, but I do contribute bits and pieces here and 
there to quite a few ( numpy, scipy, MPL, wxPython, MacPython, ... ). I 
think we want to encourage folks to be able to do that - learning a new 
VCS to test and contribute a small patch is large barrier to entry.

 The git command line works well on windows (same as on other systems),
 I used it while testing things for numpy 1.3.0 (locally, though
 because of the git-svn issue).

Somehow, command-line anything is kind of painful on Windows, and lots 
of folks don't like using it. I'm kind of a command-line guy, but do 
most of my work on Linux or OS-X, and only use Windows when I have to, 
and then I tend to use GUI tools there -- TortoiseSVN, for instance, 
even though I use command line SVN on *nix systems.


 There will always be arguments for svn being more supported, but
 doesn't this sounds like matlab vs numpy/scipy ? There will always be
 people who will find the  scipy stack not good, not integrated - 

right -- and there are a LOT more Matlab users, even though it costs a 
lot, and is a very limited language.

 still, we use numpy/scipy. git is not better than svn in every way,
 but at least to me, the question is more is git better than svn
 overall

To carry the analogy above further, I use python/numpy/scipy rather than 
Matlab for a few major reasons:

* cost/licensing -- we're only considering open source VCS here anyway.

* numpy is more powerful/flexible -- That's why we're considering moving 
to a DVCS from SVN at all -- I think it's almost a foregone conclusion 
that we'll make that move -- the question is not if, but when and which one?

* I use Python for a bunch of other stuff Matlab is not suitable for -- 
This is my argument about usability and tool support. A few years back, 
CVS was a standard, now SVN is. I like that I can use the same tool to 
contribute to a whole bunch of OS projects, and I use it to manage all 
my projects as work. It seems many in the OS world are moving to a DVCS 
-- but there are three major ones in play: git, Hg and bzr -- I don't 
know enough about any of them to say what I prefer, but I really don't 
want to have to learn all three! And if I do, it would be nice if there 
were semi-similar interfaces for them all: tortoise, for instance.

Anyway, it's not a deal-breaker, but tool support across platforms is 
important, and should be considered. And I do think that Windows is just 
as important to numpy/scipy as it is to Python.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

 * I use Python for a bunch of other stuff Matlab is not suitable for --
 This is my argument about usability and tool support. A few years back,
 CVS was a standard, now SVN is. I like that I can use the same tool to
 contribute to a whole bunch of OS projects, and I use it to manage all
 my projects as work. It seems many in the OS world are moving to a DVCS
 -- but there are three major ones in play: git, Hg and bzr -- I don't
 know enough about any of them to say what I prefer, but I really don't
 want to have to learn all three! And if I do, it would be nice if there
 were semi-similar interfaces for them all: tortoise, for instance.

Unfortunately, one has to learn all 3 (I need to use bzr for ipython,
hg for Sage, maybe soon some other projects and git for everything
else). But it's not difficult.  I think it's like learning bash and
then couple commands from tcsh and zsh just to be able to survive.

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sat, Apr 11, 2009 at 1:43 AM, Christopher Barker
chris.bar...@noaa.gov wrote:
 David Cournapeau wrote:
 we're really better off with a system with
 good tool support on all platforms.

 Why ? We are not python, where many core developers work on windows.

 As I understand it there is a dearth of Python developers on Windows,
 too...

Yes, but several highly visible python committers contributed a lot of
windows specific changes, or are windows users only. And a lot of
people who integrate python are windows shops. That was an argument
stated by several significant contributors against git.

Today, I think Josef is the main contributor who mostly uses windows -
there is me, too, actually :)

 But anyway, we probably want MORE Windows folks contributing, not
 fewer.

Yes, sure. But the fact is that there are not many windows developers.
And that's kind of inherent to the platform I believe. For many open
source projects which are cross-platform, there are very few windows
developers. For numpy/scipy, you almost must install mingw compilers,
all this being command line. I wish there was a developer who would
handle windows specifics for me :)

 Another key is the core developers concept -- I'm not a core developer
 on any major OS project, but I do contribute bits and pieces here and
 there to quite a few ( numpy, scipy, MPL, wxPython, MacPython, ... ). I
 think we want to encourage folks to be able to do that - learning a new
 VCS to test and contribute a small patch is large barrier to entry.

Yes, I agree core developer is a bit artificial and dangerous
concept. But for open source contribution, I think it is pretty clear
you will have to learn git. There are just so many projects which use
it now (all the freedesktop stuff, ror, gnome, perl, vlc, etc...).
Also, several people stated that they would be more willing to
contribute to numpy/scipy if it were under git. Now, granted, that's
just talk and guesses - but not more than the influence of git on
windows developers.

 Somehow, command-line anything is kind of painful on Windows, and lots
 of folks don't like using it. I'm kind of a command-line guy, but do
 most of my work on Linux or OS-X, and only use Windows when I have to,
 and then I tend to use GUI tools there -- TortoiseSVN, for instance,
 even though I use command line SVN on *nix systems.

Yes, command line on windows is not great, for various reasons. But I
think that's a good argument for svn and against *any* DVCS - because
frankly, all those GUI tools suck on windows ATM, be it hg, bzr or
git. I've just tried tortoisehg, and it is still really rough, not
really better than tortoisegit for what I can see. Heck, I find
tortoisesvn really rough, compared to things I have seen under good
IDE (I use very few GUI tools - but when I do, I expect top notch
stuff - which open source is rarely good at as far as GUI are
concerned).

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

David Cournapeau wrote:
 Eric Firing wrote:
 Speaking to Josef: does tortoise-hg provide a satisfactory windows gui, 
 from your standpoint?
   
 
 Another solution may be eclipse integration. I don't know if that would
 work for Josef, but there is a git plugin for eclipse, and I can at
 least clone branches from a remote repository, and work with it.
 
 Is there a hg eclipse plugin ? I am not very knowledgeable about IDE,

I'm not, either, but yes, there is a mercurial plugin for eclipse. 
Eclipse has devoted fans, but in the exploration my colleague and I have 
done, we have found it very heavy-weight and cumbersome; it doesn't look 
like we will adopt it.

Eric

 
 David
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Christopher Barker]

Well, there is a LOT to consider here, and I have virtually no 
experience with any of the DVCSs, so I don't have any conclusions to 
offer, but:

Windows support matters.
Tool support matters.

Those should be taken into consideration when making a choice.

-CHB

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

David Cournapeau wrote:
 Eric Firing wrote:
 This is simply wrong.  Mercurial uses hard links for cloning a repo that 
 is on the same disk, so it is faster and much more space-efficient than 
 copying the files.
 
 Yes, but maybe Ondrej talks about an older hg version ? Hg could not
 handle NTFS hardlink for some time, but it does now if you have pywin32.
 
 And still, switching between branches is faster in git than in hg, for
 some technical reasons I can't really explain (but can be found on the

efir...@manini:~/programs/py/mpl/mpl_hgtestclone3$ hg up v0_98_5_maint
1957 files updated, 0 files merged, 90 files removed, 0 files unresolved
efir...@manini:~/programs/py/mpl/mpl_hgtestclone3$ hg up default
262 files updated, 0 files merged, 1785 files removed, 0 files unresolved

On my laptop, switching back and forth between the two active branches 
of mpl takes about 3 s for the first and 2 s for the second, timed by 
counting in my head.

 ML archives). But as I said previously, speed is not really an argument
 for me. If hg is fast enough for python, it is obviously fast enough for
 numpy and scipy. As long as it does not takes minutes to merge/review
 the 5 lines difference between two branches as is the case in svn right
 now, I am happier :)
 
  But if you do want named branches in a given repo, 
 you can have that also with hg.  Granted, it has not always been part of 
 hg, but it is now.  Same with rebasing and transplanting.
   
 
 As I understand, and correct me if I am wrong, the problems with named
 branches are:

I'm on thin ice here, because for my own work I have not been using 
named branches.

 - you can't remove them later, it is in the repository 'forever'

They can be removed with the strip command which is in the mq extension, 
but one must identify the root of the branch and supply that to strip. 
There may be some limits and gotchas.

 - it is not easy to make them publicly available

Maybe I'm missing something, but I don't see this problem. For example, 
see http://currents.soest.hawaii.edu/hg/hgwebdir.cgi/matplotlib_mirror/
which is a mirror of the mpl svn repo using hgsubversion.  The branches 
are there, and show up when you clone it.  A problem is that the web 
interface does not allow one to select a single branch.  The log 
command, however, does.

For very lightweight local branching there are bookmarks, which allow 
one to make a local, changeable label for a given head within a repo. 
Again, such a local branch can be eliminated via strip--although I am 
not sure there is much point in doing so.  To go this route, I suspect 
one would first commit a tag, set the bookmark, make whatever changes 
and commits are desired, etc.  The point of the tag would be to make it 
easy to tell strip where to start stripping.

Certainly, hg is simplest when used as it was originally designed, with 
separate directories for branches.  How well it can emulate some 
git-style workflows, I don't know--probably never perfectly.  There are 
tradeoffs.  Overall, it appears to me that for someone who has never 
used a VCS, or for someone used to svn, hg has a lower barrier to entry 
than git.

 
 One big potential with the way git does branching is review - gerrit
 (the code review tool used by Google for android) looks really nice.

How is the code review related to the branching options in git?

 Unfortunately, to see whether this is indeed true requires trying it,
 because git-svn cannot be used to that effect (because of branches).
 
 What would be great is to have git-svnserver, like git-cvsserver (which
 is a gateway for cvs, that is people who don't want to bother can use
 cvs to do as they do normally, and other people can use git proper). I
 find it surprising that such a tool does not exist.
 
 It is possible that hg might 
 be a better fit--a better compromise--for present *and* *potential* 
 *future* contributors to numpy, scipy, and matplotlib.
   
 
 Yes, that may be the case.
 
 Speaking to David: is git branch handling vastly preferable to both of 
 the branch styles available in hg?
   
 
 Besides git, I am mostly familiar with bzr, which has the branch is a
 different directory concept (but no named branches). I think bzr is
 very confusing for advanced workflows in relation to this UI (I am too
 lazy to restate my reasons, see here:
 http://cournape.wordpress.com/2008/10/30/going-away-from-bzr-toward-git).
 
 When I tried hg (version 0.8 maybe ?), there was little support for
 named branches, but this has changed since I believe. When you have
 different repositories for different branches, comparisons between
 branches are difficult. This was the case in bzr. Is this the case in hg
 ? For example, can you log a subdirectory between two branches, easily
 review files changes between branches/tags/etc... For the release
 process, I find this very useful - but this can be somewhat alleviated
 with git-svn without forcing anyone using it.

You can easily do diffs between 

Re: [Numpy-discussion] DVCS at PyCon

[Matthew Brett]

Hi,

I enjoyed this quote from http://www.eecs.harvard.edu/~cduan/technical/git/

Summary: You can only really use Git if you understand how Git works.

When I first started using Git, I read plenty of tutorials, as well
as the user manual. Though I picked up the basic usage patterns and
commands, I never felt like I grasped what was going on “under the
hood”, so to speak. Frequently this resulted in cryptic error
messages, caused by my random guessing at the right command to use at
a given time. These difficulties worsened as I began to need more
advanced (and less well documented) features.

After a few months, I started to understand those under-the-hood
concepts. Once I did, suddenly everything made sense. I could
understand the manual pages and perform all sorts of source control
tasks. Everything that seemed so cryptic and obscure now was perfectly
clear.
Understanding Git

The conclusion I draw from this is that you can only really use Git if
you understand how Git works. Merely memorizing which commands you
should run at what times will work in the short run, but it’s only a
matter of time before you get stuck or, worse, break something.

Best,

Matthew
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[josef . pktd]

On Fri, Apr 10, 2009 at 5:47 PM, Matthew Brett matthew.br...@gmail.com wrote:
 Hi,

 I enjoyed this quote from http://www.eecs.harvard.edu/~cduan/technical/git/

 Summary: You can only really use Git if you understand how Git works.

 When I first started using Git, I read plenty of tutorials, as well
 as the user manual. Though I picked up the basic usage patterns and
 commands, I never felt like I grasped what was going on “under the
 hood”, so to speak. Frequently this resulted in cryptic error
 messages, caused by my random guessing at the right command to use at
 a given time. These difficulties worsened as I began to need more
 advanced (and less well documented) features.

 After a few months, I started to understand those under-the-hood
 concepts. Once I did, suddenly everything made sense. I could
 understand the manual pages and perform all sorts of source control
 tasks. Everything that seemed so cryptic and obscure now was perfectly
 clear.
 Understanding Git

 The conclusion I draw from this is that you can only really use Git if
 you understand how Git works. Merely memorizing which commands you
 should run at what times will work in the short run, but it’s only a
 matter of time before you get stuck or, worse, break something.


break something:

I updated my eclipse so I can try out the git eclipse plugin. Except
for a description how to clone a github repository and push back to
it, I didn't find much information on the internet.

cloning from a remote repository (pymvpa), setting it up for local
version control in eclipse and converting to a pydev project went very
easily. Creating local branches and a clone in a parallel directory
tree also worked.

From then on its working mostly blind. Working with branches in one
repository doesn't clearly indicate which branch I'm in and which
branch my files belong to. `checkout` doesn't appear to change the
visible files on the hard drive as with the command line, switching a
branch with `reset` can be soft, mixed or hard. `hard` changes the
files with a warning that all edits will be overwritten, but it
doesn't tell whether there are any uncommitted changes in files.

Fetching between clones seemed to work, there are still some things
that I need to figure out, it wasn't always clear whether my commits
actually happened or not. But finally with switching around, I managed
to get a circular reference in my clone, and now I cannot access it
as git repository any more. On the command line, git says this is not
a repository. So I guess it's gone with all the changes that are not
currently on the file system.

I still miss a git directory browser with status information for each
file, and I still didn't manage to get diffs between branches or
clones. I can fetch or push, but I cannot see directly what it is that
I'm pulling or pushing, except maybe a long alphanumeric status code.

Without a help file, I wasn't sure what I was doing, but, for sure,
git eclipse is not foolproof and not very self-explanatory.

For someone used to a real and not a virtual file system, I will, for
now, stay away from saving any of my edits in branches, that might
disappear when I make a mistake. And both git gui and the eclipse
plugin seem to require still some work before they are really useful,
unless there are some working examples and recipes to proof my
impression wrong.
But from the webpages of the gui and eclipse plugin, there seems to be
currently a lot of work going on.

Simple cloning from and committing to a real remote repository seems
to work easily enough, but then there isn't much reason to switch away
from svn, if maintaining several local branches is a risky pain.

So for users who don't get it, the branch system of bazar and
mercurial is a lot more intuitive than git.

Josef
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

Matthew Brett wrote:
 Hi,
 
 I enjoyed this quote from http://www.eecs.harvard.edu/~cduan/technical/git/
 
 Summary: You can only really use Git if you understand how Git works.

Matthew,

Nice link, thank you.

Another couple of quotes from that tutorial:

Important note: if there are any uncommitted changes when you run git 
checkout, Git will behave very strangely. The strangeness is predictable 
and sometimes useful, but it is best to avoid it. All you need to do, of 
course, is commit all the new changes before checking out the new head.

Important note: Git can get very confused if there are uncommitted 
changes in the files when you ask it to perform a merge. So make sure to 
commit whatever changes you have made so far before you merge.


Sounds like booby traps for occasional users, or for people who are 
multitasking a little too much.  The hg UI approach is different: it 
blocks that sort of thing with a warning, and provides override options 
when needed.

And for comic relief, here is a line from a git man page:

The state you are in while your HEAD is detached is not recorded by any
branch...

It hurts to even think about such a state...

Eric
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sat, Apr 11, 2009 at 10:30 AM,  josef.p...@gmail.com wrote:


 I updated my eclipse so I can try out the git eclipse plugin. Except
 for a description how to clone a github repository and push back to
 it, I didn't find much information on the internet.

FWIW, I tried the eclipse plugin yesterday, and I did not understand
anything at all about it either. I assumed it was because I was not
familiar with eclipse, but from what you say, it looks like it is
seriously broken.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing efir...@hawaii.edu wrote:


 Important note: if there are any uncommitted changes when you run git
 checkout, Git will behave very strangely. The strangeness is predictable
 and sometimes useful, but it is best to avoid it. All you need to do, of
 course, is commit all the new changes before checking out the new head.

If by strange and confused, the OP means refuse to change branch, then
yes. Otherwise, I have no idea what he is talking about. Maybe an old
git version - he does not say which one he is using.

Also, it is said in the introduction that the OP was using git but did
not understand what was happening under the hood. So his conclusion is
you have to understand git internals to understand git internals ?
Sounds tautological to me.

I am all for hearing git bashing by people - but I would prefer if it
was coming after actual use of the tool.


 The state you are in while your HEAD is detached is not recorded by any
        branch...

The only occasion it happened to me was with git-svn - which I would
no advocate using as a transition path, indeed. It is great for
individual people (I use it all the time for numpy) but it is
definitely strange UI-wise sometimes.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

David Cournapeau wrote:
 On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing efir...@hawaii.edu wrote:
 
 Important note: if there are any uncommitted changes when you run git
 checkout, Git will behave very strangely. The strangeness is predictable
 and sometimes useful, but it is best to avoid it. All you need to do, of
 course, is commit all the new changes before checking out the new head.
 
 If by strange and confused, the OP means refuse to change branch, then
 yes. Otherwise, I have no idea what he is talking about. Maybe an old
 git version - he does not say which one he is using.

Could be.  All of these tools are moving targets.  The tutorial was last 
modified in June, 2008.

 
 Also, it is said in the introduction that the OP was using git but did
 not understand what was happening under the hood. So his conclusion is
 you have to understand git internals to understand git internals ?
 Sounds tautological to me.

No, I think the point of Duan's introduction was that *initially* he had 
trouble *using* git because he did not understand its internals; 
therefore he was writing a tutorial that would explain the usage in 
terms of what the commands do internally, instead of simply providing 
lists of commands to accomplish a given set of tasks.  The description 
of internals that he provides is pretty minimal, though.

 
 I am all for hearing git bashing by people - but I would prefer if it
 was coming after actual use of the tool.

Please understand, I am not trying to bash git--it is clearly an 
enormously powerful and well-made tool--and I apologize if my posts have 
appeared to tend in that direction.  I guess I am trying to keep hg from 
being dismissed too quickly, and I am trying to understand what the 
similarities and differences are, and what consequences the choice of 
one or the other would be likely to have. The quotes were from a 
tutorial http://www.eecs.harvard.edu/~cduan/technical/git/ referenced by 
Matthew.  The author of the tutorial appears to have been writing after 
actual use of git.  I certainly am not, and will say no more about it.

 
 The state you are in while your HEAD is detached is not recorded by any
branch...
 

I included the above quote because it made me laugh, and I hoped it 
would do the same for others.  That's all.

Eric

 The only occasion it happened to me was with git-svn - which I would
 no advocate using as a transition path, indeed. It is great for
 individual people (I use it all the time for numpy) but it is
 definitely strange UI-wise sometimes.
 
 David
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sat, Apr 11, 2009 at 6:16 AM, Eric Firing efir...@hawaii.edu wrote:


 On my laptop, switching back and forth between the two active branches
 of mpl takes about 3 s for the first and 2 s for the second, timed by
 counting in my head.

I think Ondrej cares more about being faster than most of us - he is
just too fast for most of us :) I don't think speed should be an
argument, because both are fast enough.


 I'm on thin ice here, because for my own work I have not been using
 named branches.

     - you can't remove them later, it is in the repository 'forever'

 They can be removed with the strip command which is in the mq extension,
 but one must identify the root of the branch and supply that to strip.
 There may be some limits and gotchas.

Ok, will look at it more closely (I have just made a hg repo from the
numpy git one on my machine). I am still confused about how named
branches are supposed to work (the hg book is a a bit light on this).
For example, let's say I want to create a branch from a given
revision/tag, how should I do it ? Since hg branch does not take an -r
revision, I tried to create the branch first, and then use hg up -r N,
but it did not commit as I expected from a git perspective:

hg branch foo
hg up -r 500
hg log # show me last revision independently from the branch changes.
Not so surprising given that the branch was created from the tip of
default.
hg ci -m bla
hg branches # no branch foo ?

What am I doing wrong ?

 For very lightweight local branching there are bookmarks, which allow
 one to make a local, changeable label for a given head within a repo.
 Again, such a local branch can be eliminated via strip--although I am
 not sure there is much point in doing so.  To go this route, I suspect
 one would first commit a tag, set the bookmark, make whatever changes
 and commits are desired, etc.  The point of the tag would be to make it
 easy to tell strip where to start stripping.

Ah, I think I was confused between named branches and bookmarks. From
the description of bookmarks, this actually looks nearer to the git
cheap branch concept. I should really try it to get a good
understanding, though.

 Overall, it appears to me that for someone who has never
 used a VCS, or for someone used to svn, hg has a lower barrier to entry
 than git.

It may be true for branches - but the basic
(commit/log/pull/push/clone) is almost exactly the same between the
two of them (and for bzr as well). So for someone who keeps a svn-like
workflow, I don't see big differences between the tools.


 One big potential with the way git does branching is review - gerrit
 (the code review tool used by Google for android) looks really nice.

 How is the code review related to the branching options in git?

A good explanation is there:

http://groups.google.com/group/repo-discuss/browse_thread/thread/f8365b4217157cd4/2c3c729082bdd1b7?#2c3c729082bdd1b7

If you have used rietveld (from which gerrit was forked), it is a bit
similar UI-wise, but git makes some things more automatic (if the
review is good, the changes are automatically merged, for example).
But again, I said potentially because we would need to really try it
with other people for review to get a real idea. If there is one thing
that I learned why using different tools, it is that the only way to
know about them is to stop reading about them, and actually use them
:)

 You can easily do diffs between changesets within a repo, regardless of
 whether they are on different named branches, and the diffs can be
 specific to a file or subdirectory.  Changesets can be identified by
 branchnames, tags, bookmarks, sequential numbers, or hash ID. For diffs
 between directories, there is an rdiff extension that is not distributed
 with hg.  I haven't tried it.

Yes, I have just tried this as well, and it works as I expected - once
I understand that what mercurial calls a revision includes branch name
as well. It is a bit slower than git, but really nothing prohibitive.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing efir...@hawaii.edu wrote:


 Please understand, I am not trying to bash git--it is clearly an
 enormously powerful and well-made tool--and I apologize if my posts have
 appeared to tend in that direction.

No need to apologize, I think I used the work bashing inappropriately
- I just wanted to say that the only way to understand the differences
between the tools is to use them. Reading about them will only confuse
you in my own experience. For example, I tried git once a long time
ago (during an infamous discussion between git and bzr developers on
the bzr M), could not understand a thing about it, and did not
understand any point in it except speed. Then I was forced to use git
because of bzr-svn constant frustrations - and I ended up to really
like it.

At last scipy conference, I tried to sell git advantages to Stefan
(a long time bzr user as well), who was far from convinced from my
explanations and my ranting. Then later he used it and liked it. Of
course, the logical conclusion could be that I am just very bad at
explaining why I like git :)

 I guess I am trying to keep hg from
 being dismissed too quickly

I am not dismissing anything - certainly if many people hate git, it
will be out of the possible choices.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Charles R Harris]

On Fri, Apr 10, 2009 at 8:17 PM, David Cournapeau courn...@gmail.comwrote:

 On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing efir...@hawaii.edu wrote:

 
  Important note: if there are any uncommitted changes when you run git
  checkout, Git will behave very strangely. The strangeness is predictable
  and sometimes useful, but it is best to avoid it. All you need to do, of
  course, is commit all the new changes before checking out the new head.

 If by strange and confused, the OP means refuse to change branch, then
 yes. Otherwise, I have no idea what he is talking about. Maybe an old
 git version - he does not say which one he is using.

 Also, it is said in the introduction that the OP was using git but did
 not understand what was happening under the hood. So his conclusion is
 you have to understand git internals to understand git internals ?
 Sounds tautological to me.


I think he meant that it is easier to correctly use the knobs and levers of
git if you understand what they relate to the repository, and that means
knowing how the depository tracks things. I found his exposition helpful.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sat, Apr 11, 2009 at 12:37 PM, Charles R Harris
charlesr.har...@gmail.com wrote:


 On Fri, Apr 10, 2009 at 8:17 PM, David Cournapeau courn...@gmail.com
 wrote:

 On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing efir...@hawaii.edu wrote:

 
  Important note: if there are any uncommitted changes when you run git
  checkout, Git will behave very strangely. The strangeness is predictable
  and sometimes useful, but it is best to avoid it. All you need to do, of
  course, is commit all the new changes before checking out the new head.

 If by strange and confused, the OP means refuse to change branch, then
 yes. Otherwise, I have no idea what he is talking about. Maybe an old
 git version - he does not say which one he is using.

 Also, it is said in the introduction that the OP was using git but did
 not understand what was happening under the hood. So his conclusion is
 you have to understand git internals to understand git internals ?
 Sounds tautological to me.

 I think he meant that it is easier to correctly use the knobs and levers of
 git if you understand what they relate to the repository, and that means
 knowing how the depository tracks things. I found his exposition helpful.

Yes, his exposition is well written otherwise - much better than what
you find on more google visible git expositions (I happen to think
that git is badly marketed by some vocal people). But does this
really look harder than hg ? I can't see a big difference. You need to
know about heads, branches, parents and the likes in any DVCS if you
use branches, no ?

And the ton of my previous answer was not appropriate anyway, I apologize.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Charles R Harris]

On Fri, Apr 10, 2009 at 9:49 PM, David Cournapeau courn...@gmail.comwrote:

 On Sat, Apr 11, 2009 at 12:37 PM, Charles R Harris
 charlesr.har...@gmail.com wrote:
 
 
  On Fri, Apr 10, 2009 at 8:17 PM, David Cournapeau courn...@gmail.com
  wrote:
 
  On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing efir...@hawaii.edu
 wrote:
 
  
   Important note: if there are any uncommitted changes when you run git
   checkout, Git will behave very strangely. The strangeness is
 predictable
   and sometimes useful, but it is best to avoid it. All you need to do,
 of
   course, is commit all the new changes before checking out the new
 head.
 
  If by strange and confused, the OP means refuse to change branch, then
  yes. Otherwise, I have no idea what he is talking about. Maybe an old
  git version - he does not say which one he is using.
 
  Also, it is said in the introduction that the OP was using git but did
  not understand what was happening under the hood. So his conclusion is
  you have to understand git internals to understand git internals ?
  Sounds tautological to me.
 
  I think he meant that it is easier to correctly use the knobs and levers
 of
  git if you understand what they relate to the repository, and that means
  knowing how the depository tracks things. I found his exposition helpful.

 Yes, his exposition is well written otherwise - much better than what
 you find on more google visible git expositions (I happen to think
 that git is badly marketed by some vocal people). But does this
 really look harder than hg ? I can't see a big difference. You need to
 know about heads, branches, parents and the likes in any DVCS if you
 use branches, no ?


I think hg works in a similar manner to git. At least Linus said so in that
old google talk ;) But hg doesn't/didn't have the same superstructure built
on top of the basic repository idea. However, I'm not familiar with the hg
internals...


 And the ton of my previous answer was not appropriate anyway, I apologize.


Heh. And on good Friday too ;)

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

David Cournapeau wrote:
 On Sat, Apr 11, 2009 at 6:16 AM, Eric Firing efir...@hawaii.edu wrote:
 
 On my laptop, switching back and forth between the two active branches
 of mpl takes about 3 s for the first and 2 s for the second, timed by
 counting in my head.
 
 I think Ondrej cares more about being faster than most of us - he is
 just too fast for most of us :) I don't think speed should be an
 argument, because both are fast enough.
 
 I'm on thin ice here, because for my own work I have not been using
 named branches.

 - you can't remove them later, it is in the repository 'forever'
 They can be removed with the strip command which is in the mq extension,
 but one must identify the root of the branch and supply that to strip.
 There may be some limits and gotchas.

Also, if you just want to remove the branch from the list of branches, 
as opposed to expunging the changesets it contains, then you can use
hg commit --close_branch.  Strangely, though, you then have to use the 
-a option of branches to exclude it from the list; and you can still go 
back to it and resume work on it.

 
 Ok, will look at it more closely (I have just made a hg repo from the
 numpy git one on my machine). I am still confused about how named
 branches are supposed to work (the hg book is a a bit light on this).
 For example, let's say I want to create a branch from a given
 revision/tag, how should I do it ? Since hg branch does not take an -r
 revision, I tried to create the branch first, and then use hg up -r N,
 but it did not commit as I expected from a git perspective:
 
 hg branch foo
 hg up -r 500
 hg log # show me last revision independently from the branch changes.
 Not so surprising given that the branch was created from the tip of
 default.
 hg ci -m bla
 hg branches # no branch foo ?
 
 What am I doing wrong ?

Try something like this sequence (substituting your editor for z and 
adding random junk each time):

  504  mkdir hgtest
   505  cd hgtest
   506  hg init
   507  z test.txt
   509  hg add
   510  hg commit -m first
   511  z test.txt
   512  hg commit -m second
   513  z test.txt
   514  hg commit -m third
   515  hg log
   516  hg up -r 1
   517  hg branch from1
   518  hg tag from1tag
   519  hg status
   520  hg log
   521  z test.txt
   522  hg commit -m first change after tag on from1
   523  hg up -r default
   524  cat test.txt
   525  history
   526  hg branches
   527  hg branch
   528  hg up -r from1
   529  hg branch

hg branch foo

saves the name foo to be used as the branch name *starting* with the 
next commit.  I arbitrarily made that next commit a tag to identify the 
base of the new branch, and then made additional commits.

hg up -r foo

switches the working directory to the tip (head) of branch foo; hg up 
does all changing of location within the repo, regardless of whether the 
location is identified by a branch, a tag, etc.

hg branches

lists branches; with -a it omits closed branches.

One oddity you may notice in the example above is that the changeset 
resulting from the tag command is *after* the changeset that gets 
tagged.  Tags are just entries in a revision-controlled file, so the tag 
command changes that file, and then commits the change.  Any revision 
can be tagged at any time.

 
 For very lightweight local branching there are bookmarks, which allow
 one to make a local, changeable label for a given head within a repo.
 Again, such a local branch can be eliminated via strip--although I am
 not sure there is much point in doing so.  To go this route, I suspect
 one would first commit a tag, set the bookmark, make whatever changes
 and commits are desired, etc.  The point of the tag would be to make it
 easy to tell strip where to start stripping.
 
 Ah, I think I was confused between named branches and bookmarks. From
 the description of bookmarks, this actually looks nearer to the git
 cheap branch concept. I should really try it to get a good
 understanding, though.

I would not be surprised if bookmarks were directly inspired by that. 
There is also a localbranch extension, but it is not included in the 
distribution and hasn't gotten much attention. I have the sense that 
bookmarks were designed to accomplish the same thing.


Eric
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Sat, Apr 11, 2009 at 1:00 PM, Charles R Harris
charlesr.har...@gmail.com wrote:

 I think hg works in a similar manner to git. At least Linus said so in that
 old google talk ;)

Yes, compared to svn, hg, git and bzr are quite similar in a way. I
think the differences still matter, though.

 But hg doesn't/didn't have the same superstructure built
 on top of the basic repository idea.

Yes, it means you can build a lot of things around git, which is very
flexible. You have the repo tool to deal with many modules, gerrit for
code review, etc... But this flexibility comes with a price at the UI
level - price which has diminished a lot, but is still not zero. I
think this cost is nearly 0 for simple workflows, but it looks like I
am relatively alone on this :)

I could see (but still not entirely convinced) that hg could be
simpler but from the hg book, it seems that  that's only because it
hides or prevent some advanced things (what Teo Tso' means with git
has more legs http://tytso.livejournal.com/29467.html). And it has
some things similar to bzr which I personally dislike deeply (simple
revision). But that's a personal preference which does not weight as
much for numpy in general.

I would really need to use hg on a daily basis to get a good idea,
specially w.r.t branch handling - that takes time in any VCS. That's
the only way - it took me time to appreciate git branches compared to
bz's way.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Charles R Harris]

On Fri, Apr 10, 2009 at 11:25 PM, David Cournapeau courn...@gmail.comwrote:

 On Sat, Apr 11, 2009 at 1:00 PM, Charles R Harris
 charlesr.har...@gmail.com wrote:

  I think hg works in a similar manner to git. At least Linus said so in
 that
  old google talk ;)

 Yes, compared to svn, hg, git and bzr are quite similar in a way. I
 think the differences still matter, though.

  But hg doesn't/didn't have the same superstructure built
  on top of the basic repository idea.

 Yes, it means you can build a lot of things around git, which is very
 flexible. You have the repo tool to deal with many modules, gerrit for
 code review, etc... But this flexibility comes with a price at the UI
 level - price which has diminished a lot, but is still not zero. I
 think this cost is nearly 0 for simple workflows, but it looks like I
 am relatively alone on this :)


I use git myself and find it quite nice. The lack of a good gui on windows
is what keeps me from recommending it for general use. I also think it is a
good idea to move slowly on major changes like choice of source control. A
project like kde can move faster because it is mostly unix specific and the
developers aren't likely to complain about the command line.

It seems that designing an intuitive gui that fits a dvcs isn't all that
easy, and git is a bit of a jump because of the way it treats branches and
the irrelevence of time as opposed to change set sequence. I think these
issues will be worked out because dvcs *is* the wave of the future. And
someday numpy will make the switch.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik ond...@certik.cz wrote:

 Yes.

Do you have any windows developers (I am sorry, I am not familiar at
all with sympy)?

My main concern with git are:
 - you may need the command line
 - the index can be confusing (you can avoid learning it at first, but
still some errors won't make sense before you get it).
 - git is not discoverable (you need to read some documentation)

I tend to think those problems are not that big, and the concern
raised on python ML way overblown - but I learned the tool, and I
don't think anyone wants to alienate any numpy/scipy developer.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Wed, Apr 8, 2009 at 11:04 PM, David Cournapeau courn...@gmail.com wrote:
 On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik ond...@certik.cz wrote:

 Yes.

 Do you have any windows developers (I am sorry, I am not familiar at
 all with sympy)?

Not much.


 My main concern with git are:
  - you may need the command line

Oh, definitely. What else? :)

  - the index can be confusing (you can avoid learning it at first, but
 still some errors won't make sense before you get it).

Yes, but in fact the staging area (if this is what you mean) is in
every VCS, only it's hidden, except git, where it is made explicit.

  - git is not discoverable (you need to read some documentation)

Yes, but git help command is very detailed most of the time.


 I tend to think those problems are not that big, and the concern
 raised on python ML way overblown - but I learned the tool, and I
 don't think anyone wants to alienate any numpy/scipy developer.

Which tool did you learn? Git?

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Thu, Apr 9, 2009 at 3:04 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
 Ondrej Certik wrote:

 Yes, but in fact the staging area (if this is what you mean) is in
 every VCS, only it's hidden, except git, where it is made explicit.


 I am not sure the staging area concept is there in other vcs, because in
 git it is intrinsically linked to idea that git tracks content. It is

If you do hg add, you add to the staging area. If you do hg
commit, you commit it, together with automatically adding all changes
to the staging area as well (and committing).

I think it's the same with svn.

 powerful, and I really miss it in other DVCS, but it takes time to get
 used to - time that other people may not be willing to spend. I tried to
 write some basic instructions which totally bypass the index concept,
 but it can still bite you even in those simple cases:

 http://projects.scipy.org/numpy/wiki/GitWorkflow#Commonscenario

 Which tool did you learn? Git?


 git. Both Stefan and me really like git, but assuming we make the
 transition, we worry a bit about the transition cost for people who are
 happy with svn.

I think it won't. At least it didn't in the sympy case.

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Gael Varoquaux]

On Thu, Apr 09, 2009 at 03:04:37PM +0900, David Cournapeau wrote:
  - git is not discoverable (you need to read some documentation)

Yes, I found that when I tried to use git to quickly get a few basic
things done, I had a lot of stupid problems:

$ git stat
git: 'stat' is not a git-command

The most commonly used git commands are:
   add   Add file contents to the index

[...]

= WTF?? Every single VCS works with 'stat'. Why do I need to learn
something new.

$ git up
git: 'up' is not a git-command

[...]

= Right, I am starting to like this soft

$ git info
git: 'info' is not a git-command

[...]

= Really, you are kidding me.

$ git revert
usage: git-revert [--edit | --no-edit] [-n] commit-ish

= fsck-you, Git, I want to revert. I don't understand this error
message, I just want to revert. Seriously, I haven't figured out how to
revert. I would need to read the doc (I haven't).

I _really_ have an issue with the way git treats the user. It is pretty
Well, lad, I am the best VCS in the world, and you are going to have to
relearn your VCS-foo to use me. Great way to loose developers, IMHO. I
whish the guys could make some small usability efforts.

My 2 cents,

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

Gael Varoquaux wrote:
 On Thu, Apr 09, 2009 at 03:04:37PM +0900, David Cournapeau wrote:
   
  - git is not discoverable (you need to read some documentation)
 

 Yes, I found that when I tried to use git to quickly get a few basic
 things done, I had a lot of stupid problems:
   

The argument could be made that in any DVCS, the commands *are*
different even if the name is the same (commit and up certainly don't do
the same in svn and in bzr, for example).

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Gael Varoquaux]

On Thu, Apr 09, 2009 at 08:14:20PM +0900, David Cournapeau wrote:
 Gael Varoquaux wrote:
  On Thu, Apr 09, 2009 at 03:04:37PM +0900, David Cournapeau wrote:

   - git is not discoverable (you need to read some documentation)


  Yes, I found that when I tried to use git to quickly get a few basic
  things done, I had a lot of stupid problems:


 The argument could be made that in any DVCS, the commands *are*
 different even if the name is the same (commit and up certainly don't do
 the same in svn and in bzr, for example).

That may be true for up, in my previous examples, but not for stat, info
and revert.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

Gael Varoquaux wrote:
 That may be true for up, in my previous examples, but not for stat, info
 and revert.
   

hg does not have an info either. And for revert, st, ci, etc... what do
you feel is missing from there ?

http://projects.scipy.org/numpy/wiki/GitWorkflow

Which is an attempt to alleviate the non discoverability thing in the
context of numpy/scipy.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[josef . pktd]

On Thu, Apr 9, 2009 at 6:00 AM, Ondrej Certik ond...@certik.cz wrote:
 On Wed, Apr 8, 2009 at 11:04 PM, David Cournapeau courn...@gmail.com wrote:
 On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik ond...@certik.cz wrote:

 Yes.

 Do you have any windows developers (I am sorry, I am not familiar at
 all with sympy)?

 Not much.


 My main concern with git are:
  - you may need the command line

 Oh, definitely. What else? :)


I never commit to svn from the command line, only with a gui that lets
me easily browse any changes that I am about to commit. I use the
command line for checkouts and updates.

or else plugins to editors, eg. eclipse

For those of us, that don't use git all the time, the amount that we
have to learn and keep in mind, seems pretty high. With a gui, I can
check the menus to see what the names of the necessary commands are
and I don't have to memorize them or type help all the time to remind
me.

Josef


  - the index can be confusing (you can avoid learning it at first, but
 still some errors won't make sense before you get it).

 Yes, but in fact the staging area (if this is what you mean) is in
 every VCS, only it's hidden, except git, where it is made explicit.

  - git is not discoverable (you need to read some documentation)

 Yes, but git help command is very detailed most of the time.


 I tend to think those problems are not that big, and the concern
 raised on python ML way overblown - but I learned the tool, and I
 don't think anyone wants to alienate any numpy/scipy developer.

 Which tool did you learn? Git?

 Ondrej
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Matthieu Brucher]

2009/4/9 David Cournapeau courn...@gmail.com:
 On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik ond...@certik.cz wrote:

 Yes.

 Do you have any windows developers (I am sorry, I am not familiar at
 all with sympy)?

 My main concern with git are:
  - you may need the command line
  - the index can be confusing (you can avoid learning it at first, but
 still some errors won't make sense before you get it).
  - git is not discoverable (you need to read some documentation)

I tried to install git on my computer, as git-svn seemed so nice. I
tried git-svn and it told me that some .pm files are missing. Why did
it install git-svn if some files are missing? And why isn't it
possible to get some information on how to install those missing files
on the Internet.

git seems nice, but lacks documentation and usability :|

Matthieu
-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher
matthieu.bruc...@gmail.com wrote:
 2009/4/9 David Cournapeau courn...@gmail.com:
 On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik ond...@certik.cz wrote:

 Yes.

 Do you have any windows developers (I am sorry, I am not familiar at
 all with sympy)?

 My main concern with git are:
  - you may need the command line
  - the index can be confusing (you can avoid learning it at first, but
 still some errors won't make sense before you get it).
  - git is not discoverable (you need to read some documentation)

 I tried to install git on my computer, as git-svn seemed so nice. I
 tried git-svn and it told me that some .pm files are missing. Why did
 it install git-svn if some files are missing? And why isn't it
 possible to get some information on how to install those missing files
 on the Internet.

For which system did you install it ? I don't think git-svn work well
or at all on windows.

Otherwise, git has binary installers for every platform which matters.
Installing from sources is a bit harder than bzr/hg, but certainly
easier than svn, if you need to,

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Grissiom]

On Thu, Apr 9, 2009 at 21:38, Matthieu Brucher
matthieu.bruc...@gmail.comwrote:

 2009/4/9 David Cournapeau courn...@gmail.com:
  On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik ond...@certik.cz wrote:
 
  Yes.
 
  Do you have any windows developers (I am sorry, I am not familiar at
  all with sympy)?
 
  My main concern with git are:
   - you may need the command line
   - the index can be confusing (you can avoid learning it at first, but
  still some errors won't make sense before you get it).
   - git is not discoverable (you need to read some documentation)

 I tried to install git on my computer, as git-svn seemed so nice. I
 tried git-svn and it told me that some .pm files are missing. Why did
 it install git-svn if some files are missing? And why isn't it
 possible to get some information on how to install those missing files
 on the Internet.

 git seems nice, but lacks documentation and usability :|

 Matthieu


The saying that git lacks documentation and usability was a long-long ago
history in my eyes. Although I'm not a sympy developer nor numpy developer
but I use git for my own project and enjoy working with it. You may find
some useful documentation here:

http://git-scm.com/

and a tutorial:

http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html


What really lacks is a little bit learning and using.

-- 
Cheers,
Grissiom
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Matthieu Brucher]

2009/4/9 David Cournapeau courn...@gmail.com:
 On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher
 matthieu.bruc...@gmail.com wrote:
 2009/4/9 David Cournapeau courn...@gmail.com:
 On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik ond...@certik.cz wrote:

 Yes.

 Do you have any windows developers (I am sorry, I am not familiar at
 all with sympy)?

 My main concern with git are:
  - you may need the command line
  - the index can be confusing (you can avoid learning it at first, but
 still some errors won't make sense before you get it).
  - git is not discoverable (you need to read some documentation)

 I tried to install git on my computer, as git-svn seemed so nice. I
 tried git-svn and it told me that some .pm files are missing. Why did
 it install git-svn if some files are missing? And why isn't it
 possible to get some information on how to install those missing files
 on the Internet.

 For which system did you install it ? I don't think git-svn work well
 or at all on windows.

 Otherwise, git has binary installers for every platform which matters.
 Installing from sources is a bit harder than bzr/hg, but certainly
 easier than svn, if you need to,

Installed from source on a RH4. It complains about missing SVN/Core.pm.

Matthieu
-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Thu, Apr 9, 2009 at 11:15 PM, Matthieu Brucher

 Installed from source on a RH4. It complains about missing SVN/Core.pm.

you need the perl wrapper for subversion installed, and to set the
equivalent of PYTHONPATH for perl to it (sorry, the name of the
variable eludes me ATM, but I had to do this on a CENTOS workstation
once).

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Christopher Barker]

David Cournapeau wrote:
 I don't think git-svn work well
 or at all on windows.

This brings up a key issue for Python: git does not support Windows very 
well -- which makes sense, given its history with Linux kernel development.

I personally use SVN primarily form the command line on all systems, 
though Tortoise is very nice on Windows. It looks like there is indeed a 
TortoiseGit -- anyone know hoe complete/stable it is?

Anyway, the multi-platform and multiple tools support of SVN is amazing, 
and this is a big deal -- we're really better off with a system with 
good tool support on all platforms.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Thu, Apr 9, 2009 at 7:15 AM, Matthieu Brucher
matthieu.bruc...@gmail.com wrote:
 2009/4/9 David Cournapeau courn...@gmail.com:
 On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher
 matthieu.bruc...@gmail.com wrote:
 2009/4/9 David Cournapeau courn...@gmail.com:
 On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik ond...@certik.cz wrote:

 Yes.

 Do you have any windows developers (I am sorry, I am not familiar at
 all with sympy)?

 My main concern with git are:
  - you may need the command line
  - the index can be confusing (you can avoid learning it at first, but
 still some errors won't make sense before you get it).
  - git is not discoverable (you need to read some documentation)

 I tried to install git on my computer, as git-svn seemed so nice. I
 tried git-svn and it told me that some .pm files are missing. Why did
 it install git-svn if some files are missing? And why isn't it
 possible to get some information on how to install those missing files
 on the Internet.

 For which system did you install it ? I don't think git-svn work well
 or at all on windows.

 Otherwise, git has binary installers for every platform which matters.
 Installing from sources is a bit harder than bzr/hg, but certainly
 easier than svn, if you need to,

 Installed from source on a RH4. It complains about missing SVN/Core.pm.

One thing about git-svn is that this is not really needed if you just
use git and I installed git from source on many linuxes and clusters
and it just works, as it is just pure C. I usually just use git-svn on
my laptop/workstation, where I install the Debian/Ubuntu packages, and
I create the git repository, upload to github.com or somewhere else
and just work with the git repository.

But I agree that if it installs git-svn and it doesn't just work, it's
a big problem.

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Matthieu Brucher]

 One thing about git-svn is that this is not really needed if you just
 use git and I installed git from source on many linuxes and clusters
 and it just works, as it is just pure C. I usually just use git-svn on
 my laptop/workstation, where I install the Debian/Ubuntu packages, and
 I create the git repository, upload to github.com or somewhere else
 and just work with the git repository.

 But I agree that if it installs git-svn and it doesn't just work, it's
 a big problem.

I was inquiring the use of git with the use of one of our internal svn
repositories, just to have a feeling about it :(

Matthieu
-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Andrew Straw]

Matthieu Brucher wrote:
 One thing about git-svn is that this is not really needed if you just
 use git and I installed git from source on many linuxes and clusters
 and it just works, as it is just pure C. I usually just use git-svn on
 my laptop/workstation, where I install the Debian/Ubuntu packages, and
 I create the git repository, upload to github.com or somewhere else
 and just work with the git repository.

 But I agree that if it installs git-svn and it doesn't just work, it's
 a big problem.
 
 I was inquiring the use of git with the use of one of our internal svn
 repositories, just to have a feeling about it :(

My opinion is that attempting to use git-svn to get a feeling of git is
not a good idea. There's too much slowness of svn involved, too much
pain of trying to learn git while also trying to learn git-svn (which
itself has corner cases and such that pure git doesn't) and there's no
bidirectional 1:1 mapping between branches (that I've found),
eliminating a huge part of the joy of git -- cheap branches.

Better to start developing on a pure git project to get a feel. You
can't go wrong with sympy, for example. :)

-Andrew
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Thu, Apr 9, 2009 at 11:16 AM, Andrew Straw straw...@astraw.com wrote:
 Matthieu Brucher wrote:
 One thing about git-svn is that this is not really needed if you just
 use git and I installed git from source on many linuxes and clusters
 and it just works, as it is just pure C. I usually just use git-svn on
 my laptop/workstation, where I install the Debian/Ubuntu packages, and
 I create the git repository, upload to github.com or somewhere else
 and just work with the git repository.

 But I agree that if it installs git-svn and it doesn't just work, it's
 a big problem.

 I was inquiring the use of git with the use of one of our internal svn
 repositories, just to have a feeling about it :(

 My opinion is that attempting to use git-svn to get a feeling of git is
 not a good idea. There's too much slowness of svn involved, too much
 pain of trying to learn git while also trying to learn git-svn (which
 itself has corner cases and such that pure git doesn't) and there's no
 bidirectional 1:1 mapping between branches (that I've found),
 eliminating a huge part of the joy of git -- cheap branches.

 Better to start developing on a pure git project to get a feel. You
 can't go wrong with sympy, for example. :)

Oh, definitely. :) Here is a list of easy to fix issues:

http://code.google.com/p/sympy/issues/list?q=label:EasyToFix

if you want to learn it on some easy, but real world example. :)

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Matthieu Brucher]

 I was inquiring the use of git with the use of one of our internal svn
 repositories, just to have a feeling about it :(

 My opinion is that attempting to use git-svn to get a feeling of git is
 not a good idea. There's too much slowness of svn involved, too much
 pain of trying to learn git while also trying to learn git-svn (which
 itself has corner cases and such that pure git doesn't) and there's no
 bidirectional 1:1 mapping between branches (that I've found),
 eliminating a huge part of the joy of git -- cheap branches.

 Better to start developing on a pure git project to get a feel. You
 can't go wrong with sympy, for example. :)

 Oh, definitely. :) Here is a list of easy to fix issues:

 http://code.google.com/p/sympy/issues/list?q=label:EasyToFix

 if you want to learn it on some easy, but real world example. :)

Unfortunately, I'm investigating it for my professional use, and I
don't have a decent Internet access (i.e. without proxies).

Matthieu
-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[josef . pktd]

On Thu, Apr 9, 2009 at 1:58 PM, Ondrej Certik ond...@certik.cz wrote:
 On Thu, Apr 9, 2009 at 7:15 AM, Matthieu Brucher
 matthieu.bruc...@gmail.com wrote:
 2009/4/9 David Cournapeau courn...@gmail.com:
 On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher
 matthieu.bruc...@gmail.com wrote:
 2009/4/9 David Cournapeau courn...@gmail.com:
 On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik ond...@certik.cz wrote:

 Yes.

 Do you have any windows developers (I am sorry, I am not familiar at
 all with sympy)?

 My main concern with git are:
  - you may need the command line
  - the index can be confusing (you can avoid learning it at first, but
 still some errors won't make sense before you get it).
  - git is not discoverable (you need to read some documentation)

 I tried to install git on my computer, as git-svn seemed so nice. I
 tried git-svn and it told me that some .pm files are missing. Why did
 it install git-svn if some files are missing? And why isn't it
 possible to get some information on how to install those missing files
 on the Internet.

 For which system did you install it ? I don't think git-svn work well
 or at all on windows.

 Otherwise, git has binary installers for every platform which matters.
 Installing from sources is a bit harder than bzr/hg, but certainly
 easier than svn, if you need to,

 Installed from source on a RH4. It complains about missing SVN/Core.pm.

 One thing about git-svn is that this is not really needed if you just
 use git and I installed git from source on many linuxes and clusters
 and it just works, as it is just pure C. I usually just use git-svn on
 my laptop/workstation, where I install the Debian/Ubuntu packages, and
 I create the git repository, upload to github.com or somewhere else
 and just work with the git repository.

 But I agree that if it installs git-svn and it doesn't just work, it's
 a big problem.

 Ondrej
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion


git-svn is supposed to be available again on windows as part of
msysgit. I had it installed, but I didn't out git-svn. I removed
msysgit again since 1 GByte for this on my notebook with scarce drive
space was a waste. The installer version of git doesn't have git-svn
included.

git citool  and git gui  look pretty good

In the file browser, I'm still missing change dates, tree view doesn't
have dates to quickly see which files got changed last,  e.g.

http://projects.scipy.org/gitweb?p=scipy;a=tree;h=refs/heads/trunk;hb=trunk

for the simple usage that I tried, the windows version seems to work
pretty well.

git clone --origin svn http://projects.scipy.org/git/scipy.git scipy

ends with

error: Failed connect to projects.scipy.org:80; No error (curl_result = 7, http_
code = 0, sha1 = 9e55c6b0809e66049f808448a2ce3a1131e318fe)
error: Unable to find 9e55c6b0809e66049f808448a2ce3a1131e318fe under http://proj
ects.scipy.org/git/scipy.git
Cannot obtain needed commit 9e55c6b0809e66049f808448a2ce3a1131e318fe
while processing commit 7a429837e7ea88547711e5b3b5b9e38569fad553.
fatal: Fetch failed.


git clone   git://github.com/pv/scipy-work.git
worked without problems.

but just pushing  buttons on the gui is not enough

I created a branch but on my file system nothing happened. So I
started to read the tutorial, which says that all branches are in the
same directory. How can I edit files on the file system if I don't
know what branch I'm in?

Is there a way to have branches in different directories? I don't want
to have to start git all the time when I'm editing some files on a
branch?  I'm able to clone in a different directory, but I didn't see
an obvious way in the gui to link/compare with another clone.

I didn't manage to get a simple diff between two clones, and the error
messages are still very informative, e.g. response to failed fetch
in the gui is  fatal: unable to fork Error: Command failed.

or on the command line: fetch seems to have worked but then (following
the tutorial:

C:\Josef\work-oth\!oth\testbranches\copyofpvgit log -p master..pv/master
fatal: ambiguous argument 'master..pv/master': unknown revision or path not in t
he working tree.

ok, finally a pull from one clone to another worked, I was confused
about the different branches in the same repository with different
names, but still no diff, ...

Josef
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Fri, Apr 10, 2009 at 5:30 AM,  josef.p...@gmail.com wrote:


 In the file browser, I'm still missing change dates, tree view doesn't
 have dates to quickly see which files got changed last,  e.g.

 http://projects.scipy.org/gitweb?p=scipy;a=tree;h=refs/heads/trunk;hb=trunk

Yes, you can't see this cheaply with git (as it does not track
individual files), but I don't really understand what's useful in this
view. What matters is the commits, not the last changed files which
come from different commits.

 Cannot obtain needed commit 9e55c6b0809e66049f808448a2ce3a1131e318fe
 while processing commit 7a429837e7ea88547711e5b3b5b9e38569fad553.
 fatal: Fetch failed.

That may be a problem with the connection, or our own git
configuration. But connection errors in svn can be pretty cryptic too.
I agree the above message is bad, but not worse than MKACTIVITY not
authorized and the likes I consistently get with svn behind corporate
firewall/proxies.

At least with git I can continue working.

 I created a branch but on my file system nothing happened. So I
 started to read the tutorial, which says that all branches are in the
 same directory. How can I edit files on the file system if I don't
 know what branch I'm in?

This may be a limitation of the GUI - in the command line, you simply
do git branch to list your local branches (git status also tell you
the branch you are currently in).


 Is there a way to have branches in different directories?

I don't think you should start with all this. That's why our wiki page
does not introduce branches right away:

http://projects.scipy.org/numpy/wiki/GitWorkflow

It enables you to do what you usually do with svn, without branches
and the likes.

 I don't want
 to have to start git all the time when I'm editing some files on a
 branch?

You have to if you need to change between branches, there is no way around it.


 C:\Josef\work-oth\!oth\testbranches\copyofpvgit log -p master..pv/master
 fatal: ambiguous argument 'master..pv/master': unknown revision or path not 
 in t
 he working tree.

That's because you don't have both branches in your repository. You
need branches to compare in the same repository (directory). You can
list branches with git branch -a, and then git log branch1..branch2
will work for any two branches listed.

Same for any other command. But this is already a bit advanced usage
(and again, it is not like doing branch stuff with svn is any easier -
the svn documentation is very cryptic too on that matter). I think
what is relevant is whether the simple svn workflow can be done with
git. Trying to do branches as in svn won't work, as it is
fundamentally different.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Fri, Apr 10, 2009 at 3:56 AM, Matthieu Brucher
matthieu.bruc...@gmail.com wrote:

 Unfortunately, I'm investigating it for my professional use, and I
 don't have a decent Internet access (i.e. without proxies).

If you are behind a proxy, you have to use the (slower) http protocol.
That's actually a good argument in favor of mercurial I think, because
the fast protocol is based on http (but I am not sure https work).
Those proxy matters are indeed a real pain (I could not use svn at all
at a former company, for example). I don't think there is any easy
fix.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Fri, Apr 10, 2009 at 2:29 AM, Christopher Barker
chris.bar...@noaa.gov wrote:
 David Cournapeau wrote:
 I don't think git-svn work well
 or at all on windows.

 This brings up a key issue for Python: git does not support Windows very
 well -- which makes sense, given its history with Linux kernel development.

 I personally use SVN primarily form the command line on all systems,
 though Tortoise is very nice on Windows. It looks like there is indeed a
 TortoiseGit -- anyone know hoe complete/stable it is?

 Anyway, the multi-platform and multiple tools support of SVN is amazing,
 and this is a big deal -- we're really better off with a system with
 good tool support on all platforms.

Why ? We are not python, where many core developers work on windows.
The git command line works well on windows (same as on other systems),
I used it while testing things for numpy 1.3.0 (locally, though
because of the git-svn issue).

There will always be arguments for svn being more supported, but
doesn't this sounds like matlab vs numpy/scipy ? There will always be
people who will find the  scipy stack not good, not integrated - but
still, we use numpy/scipy. git is not better than svn in every way,
but at least to me, the question is more is git better than svn
overall, and whether a majority of contributors would agree on the
answer being the affirmative.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[josef . pktd]

On Thu, Apr 9, 2009 at 11:13 PM, David Cournapeau courn...@gmail.com wrote:
 On Fri, Apr 10, 2009 at 5:30 AM,  josef.p...@gmail.com wrote:


 In the file browser, I'm still missing change dates, tree view doesn't
 have dates to quickly see which files got changed last,  e.g.

 http://projects.scipy.org/gitweb?p=scipy;a=tree;h=refs/heads/trunk;hb=trunk

 Yes, you can't see this cheaply with git (as it does not track
 individual files), but I don't really understand what's useful in this
 view. What matters is the commits, not the last changed files which
 come from different commits.

 Cannot obtain needed commit 9e55c6b0809e66049f808448a2ce3a1131e318fe
 while processing commit 7a429837e7ea88547711e5b3b5b9e38569fad553.
 fatal: Fetch failed.

 That may be a problem with the connection, or our own git
 configuration. But connection errors in svn can be pretty cryptic too.
 I agree the above message is bad, but not worse than MKACTIVITY not
 authorized and the likes I consistently get with svn behind corporate
 firewall/proxies.

 At least with git I can continue working.

 I created a branch but on my file system nothing happened. So I
 started to read the tutorial, which says that all branches are in the
 same directory. How can I edit files on the file system if I don't
 know what branch I'm in?

 This may be a limitation of the GUI - in the command line, you simply
 do git branch to list your local branches (git status also tell you
 the branch you are currently in).


 Is there a way to have branches in different directories?

 I don't think you should start with all this. That's why our wiki page
 does not introduce branches right away:

 http://projects.scipy.org/numpy/wiki/GitWorkflow

 It enables you to do what you usually do with svn, without branches
 and the likes.

 I don't want
 to have to start git all the time when I'm editing some files on a
 branch?

 You have to if you need to change between branches, there is no way around it.


 C:\Josef\work-oth\!oth\testbranches\copyofpvgit log -p master..pv/master
 fatal: ambiguous argument 'master..pv/master': unknown revision or path not 
 in t
 he working tree.

 That's because you don't have both branches in your repository. You
 need branches to compare in the same repository (directory). You can
 list branches with git branch -a, and then git log branch1..branch2
 will work for any two branches listed.

 Same for any other command. But this is already a bit advanced usage
 (and again, it is not like doing branch stuff with svn is any easier -
 the svn documentation is very cryptic too on that matter). I think
 what is relevant is whether the simple svn workflow can be done with
 git. Trying to do branches as in svn won't work, as it is
 fundamentally different.


I was comparing this more to my short experience with bazar, after a
few hours, I had a scipy checkout and several branches in different
directories, and could relatively easily compare and merge and pull
between the different branches.

I'm very used to working out of windows explorer as my main file
access, and when I quickly edit something, I don't need to tell bzr or
svn which version I am working on, I know it from the directory
structure and can add and commit at some later point. So, for my
style, working with different clones instead of branches seems easier.
And for example, pysvn workbench lets me browse the directory tree
showing the change and commit status per directory and diff to head
and branches for each file in the gui.
The history browser seems much better in the git gui.

I managed to finally also get a diff between clones on the command
line. but in the gui, I still get the unable to fork error. The git
gui seems to still need a bit of work to be useful.

I'm not behind a proxy, just behind the wireless router, and I never
had problems with svn.

Josef
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

josef.p...@gmail.com wrote:
 So, for my
 style, working with different clones instead of branches seems easier.
   

Yes, it is.  There is no denying that git makes it more difficult for
this workflow, and that git is more difficult at first for easy tasks. I
am interested in making it as easy as possible, and if it is indeed too
difficult, then maybe git is out.

 I'm not behind a proxy, just behind the wireless router, and I never
 had problems with svn.
   

You're right, I tried on windows and Linux from my machine, and the
error is windows only, and not related to a proxy.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Thu, Apr 9, 2009 at 10:25 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
 josef.p...@gmail.com wrote:
 So, for my
 style, working with different clones instead of branches seems easier.


 Yes, it is.  There is no denying that git makes it more difficult for
 this workflow, and that git is more difficult at first for easy tasks. I
 am interested in making it as easy as possible, and if it is indeed too
 difficult, then maybe git is out.

It is maybe easier to learn how to work with different clones, but
once you start working with lots of patches and you need to reclone
all the time, then it's the wrong approach to work, as it takes lots
of time to copy the whole repository on the disk. I worked like that
with mercurial and I hated it, especially once I started to have ~15
branches.

Git branches are cheap and fast.

Besides, imho, you can work with different clones with git too, if you want.

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Stéfan van der Walt]

2009/4/6 Ondrej Certik ond...@certik.cz:
 FWIW, I tend to agree that Hg is less disruptive than git when coming
 from svn, at least for the simple tasks (I don't know hg enough to have
 a really informed opinion for more advanced workflows).

 Yes, git rocks.

Did Sympy move from Hg to Git?  If so, could you give us an overview
of the pros and cons you experienced?

Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

2009/4/7 Stéfan van der Walt ste...@sun.ac.za:
 2009/4/6 Ondrej Certik ond...@certik.cz:
 FWIW, I tend to agree that Hg is less disruptive than git when coming
 from svn, at least for the simple tasks (I don't know hg enough to have
 a really informed opinion for more advanced workflows).

 Yes, git rocks.

 Did Sympy move from Hg to Git?

Yes.

 If so, could you give us an overview
 of the pros and cons you experienced?

Here are some my (subjective) observations:

1) I think all developers were able to learn git pretty easily. See also:

http://wiki.sympy.org/wiki/Git_hg_rosetta_stone

2) git is faster

3) it boosted my productivity a lot, thanks to branches. Previously I
was copying the whole directories with sympy, everytime someone sended
a patch, just to try it. I know that hg has branches too, but imho
working with them is a pain, as you can't rebase patches easily, no
interactive rebase etc and also branches were in git from the
beginning, so it's very polished. Hg is catching up I guess, but some
things are still missing.

4) no need to learn mercurial queues, just learn git and git rebase
-i, and that's all I ever need (and it's actually more powerful than
MQ). So git is simpler.


Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Ondrej Certik]

On Mon, Mar 30, 2009 at 10:59 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
 Eric Firing wrote:

 I agree.  The PEP does not show overwhelming superiority (or, arguably,
 even mild superiority) of any alternative

 I think this PEP was poorly written. You can't see any of the
 advantage/differences of the different systems. Some people even said
 they don't see the differences with svn. I think the reason partly is
 that the PEP focused on existing python workflows, but the whole point,
 at least for me, is to change the general workflow (for reviews, code
 contributions, etc...). Stephen J. Turnbull sums it up nicely:

 http://mail.python.org/pipermail/python-dev/2009-March/087968.html

 FWIW, I tend to agree that Hg is less disruptive than git when coming
 from svn, at least for the simple tasks (I don't know hg enough to have
 a really informed opinion for more advanced workflows).

Yes, git rocks.

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

Eric Firing wrote:

 I agree.  The PEP does not show overwhelming superiority (or, arguably, 
 even mild superiority) of any alternative

I think this PEP was poorly written. You can't see any of the
advantage/differences of the different systems. Some people even said
they don't see the differences with svn. I think the reason partly is
that the PEP focused on existing python workflows, but the whole point,
at least for me, is to change the general workflow (for reviews, code
contributions, etc...). Stephen J. Turnbull sums it up nicely:

http://mail.python.org/pipermail/python-dev/2009-March/087968.html

FWIW, I tend to agree that Hg is less disruptive than git when coming
from svn, at least for the simple tasks (I don't know hg enough to have
a really informed opinion for more advanced workflows).

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Bruce Southey]

David Cournapeau wrote:
 Hi Travis,

 On Sat, Mar 28, 2009 at 11:54 PM, Travis E. Oliphant
 oliph...@enthought.com wrote:
   
 FYI from PyCon

 Here at PyCon, it has been said that Python will be moving towards DVCS
 and will be using bzr or mecurial, but explicitly *not* git.   It would
 seem that *git* got the lowest score in the Developer survey that
 Brett Cannon did.
 

 It is interesting how those tools are viewed so differently in
 different communities. I am too quite doubtful about the validity of
 those surveys :)

   
 The reasons seem to be:

  * git doesn't have good Windows clients
 

 Depending on what is meant by good windows client (GUI, IDE
 integration), it is true, but then neither do bzr or hg have good
 clients, so I find this statement a bit strange. What is certainly
 true is that git developers care much less about windows than bzr (and
 hg ?). For example, I would guess git will never care much about case
 insensitive fs, etc... (I know bzr developers worked quite a bit on
 this).

   
  * git is not written with Python
 

 I can somewhat understand why it matters to python, but does it matter to us ?

 There are definitely strong arguments against git - but I don't think
 being written in python is a strong one. The lack of a good window
 support is a good argument against changing from svn, but very
 unconvincing compared to other tools. Git has now so much more
 manpower compared to hg and bzr (many more project use it: the list of
 visible projects using git is becoming quite impressive) - from a 3rd
 party POV, I think git is much better set up than bzr and hg. Gnome
 choosing git could be significant (they made the decision a couple of
 days ago).

   
 I think the sample size was pretty small to be making decisions on
 (especially when most opinions where un-informed).
 

 Most people just choose the one they first use. Few people know
 several DVCS. Pauli and me started a page about arguments pro/cons git
 - it is still very much work in progress:

 http://projects.scipy.org/numpy/wiki/GitMigrationProposal

 Since few people are willing to try different systems, we also started
 a few workflows (compared to svn):

 http://projects.scipy.org/numpy/wiki/GitWorkflow

 FWIW, I have spent some time to look at converting svn repo to git,
 with proper conversion of branches, tags, and other things. I have
 converted my own scikits to git as a first trial (I have numpy
 converted as well, but I did not put it anywhere to avoid confusion).
 This part of the problem would be relatively simple to handle.

 cheers,

 David
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion
   
It is now official that Python will switch to Mercurial (Hg):
http://thread.gmane.org/gmane.comp.python.devel/102706

Not that it directly concerns me, but this is rather surprising given:
http://www.python.org/dev/peps/pep-0374/

Hopefully more details will be provided in the near future.

Bruce
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Alan G Isaac]

On 3/30/2009 5:16 PM Bruce Southey apparently wrote:
 It is now official that Python will switch to Mercurial (Hg):
 http://thread.gmane.org/gmane.comp.python.devel/102706
 
 Not that it directly concerns me, but this is rather surprising given:
 http://www.python.org/dev/peps/pep-0374/


http://www.python.org/dev/peps/pep-0374/#chosen-dvcs

;-)
Alan Isaac

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

On Tue, Mar 31, 2009 at 6:16 AM, Bruce Southey bsout...@gmail.com wrote:
 It is now official that Python will switch to Mercurial (Hg):
 http://thread.gmane.org/gmane.comp.python.devel/102706

 Not that it directly concerns me, but this is rather surprising given:
 http://www.python.org/dev/peps/pep-0374/

I don't think it is: as Guido said in his email, someone has to make
the decision, and endless discussion go nowhere, because you can
always make arguments for one or the other. Since some core developers
are strongly against git (Martin Loewis for example), and given that
hg is used by several core python developers already, I think it makes
sense.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[Eric Firing]

David Cournapeau wrote:
 On Tue, Mar 31, 2009 at 6:16 AM, Bruce Southey bsout...@gmail.com wrote:
 It is now official that Python will switch to Mercurial (Hg):
 http://thread.gmane.org/gmane.comp.python.devel/102706

 Not that it directly concerns me, but this is rather surprising given:
 http://www.python.org/dev/peps/pep-0374/
 
 I don't think it is: as Guido said in his email, someone has to make
 the decision, and endless discussion go nowhere, because you can
 always make arguments for one or the other. Since some core developers
 are strongly against git (Martin Loewis for example), and given that
 hg is used by several core python developers already, I think it makes
 sense.

I agree.  The PEP does not show overwhelming superiority (or, arguably, 
even mild superiority) of any alternative; I think the different systems 
have been tending to converge in their capabilities, and all are 
serviceable.  Mercurial *can* be viewed as easier to learn and use than 
git, and much faster than bzr.  Perhaps of interest to the numpy 
community is that mercurial is already in use by Sphinx, sage, and cython.

Disclosure: I use and like hg.

Eric

 
 cheers,
 
 David
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] DVCS at PyCon

[Travis E. Oliphant]

FYI from PyCon

Here at PyCon, it has been said that Python will be moving towards DVCS 
and will be using bzr or mecurial, but explicitly *not* git.   It would 
seem that *git* got the lowest score in the Developer survey that 
Brett Cannon did. 

The reasons seem to be:

  * git doesn't have good Windows clients
  * git is not written with Python


I think the sample size was pretty small to be making decisions on 
(especially when most opinions where un-informed).   I don't know if 
it matters that NumPy / SciPy use the same DVCS as Python, but it's a 
data-point.

-Travis

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] DVCS at PyCon

[David Cournapeau]

Hi Travis,

On Sat, Mar 28, 2009 at 11:54 PM, Travis E. Oliphant
oliph...@enthought.com wrote:

 FYI from PyCon

 Here at PyCon, it has been said that Python will be moving towards DVCS
 and will be using bzr or mecurial, but explicitly *not* git.   It would
 seem that *git* got the lowest score in the Developer survey that
 Brett Cannon did.

It is interesting how those tools are viewed so differently in
different communities. I am too quite doubtful about the validity of
those surveys :)

 The reasons seem to be:

  * git doesn't have good Windows clients

Depending on what is meant by good windows client (GUI, IDE
integration), it is true, but then neither do bzr or hg have good
clients, so I find this statement a bit strange. What is certainly
true is that git developers care much less about windows than bzr (and
hg ?). For example, I would guess git will never care much about case
insensitive fs, etc... (I know bzr developers worked quite a bit on
this).

  * git is not written with Python

I can somewhat understand why it matters to python, but does it matter to us ?

There are definitely strong arguments against git - but I don't think
being written in python is a strong one. The lack of a good window
support is a good argument against changing from svn, but very
unconvincing compared to other tools. Git has now so much more
manpower compared to hg and bzr (many more project use it: the list of
visible projects using git is becoming quite impressive) - from a 3rd
party POV, I think git is much better set up than bzr and hg. Gnome
choosing git could be significant (they made the decision a couple of
days ago).

 I think the sample size was pretty small to be making decisions on
 (especially when most opinions where un-informed).

Most people just choose the one they first use. Few people know
several DVCS. Pauli and me started a page about arguments pro/cons git
- it is still very much work in progress:

http://projects.scipy.org/numpy/wiki/GitMigrationProposal

Since few people are willing to try different systems, we also started
a few workflows (compared to svn):

http://projects.scipy.org/numpy/wiki/GitWorkflow

FWIW, I have spent some time to look at converting svn repo to git,
with proper conversion of branches, tags, and other things. I have
converted my own scikits to git as a first trial (I have numpy
converted as well, but I did not put it anywhere to avoid confusion).
This part of the problem would be relatively simple to handle.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion