[Numpy-discussion] DVCS at PyCon
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
Hi Travis, On Sat, Mar 28, 2009 at 11:54 PM, Travis E. Oliphant 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
Re: [Numpy-discussion] DVCS at PyCon
David Cournapeau wrote: > Hi Travis, > > On Sat, Mar 28, 2009 at 11:54 PM, Travis E. Oliphant > 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
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
On Tue, Mar 31, 2009 at 6:16 AM, Bruce Southey 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
David Cournapeau wrote: > On Tue, Mar 31, 2009 at 6:16 AM, Bruce Southey 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
Re: [Numpy-discussion] DVCS at PyCon
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
On Mon, Mar 30, 2009 at 10:59 PM, David Cournapeau 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
2009/4/6 Ondrej Certik : >> 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
2009/4/7 Stéfan van der Walt : > 2009/4/6 Ondrej Certik : >>> 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
On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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
On Wed, Apr 8, 2009 at 11:04 PM, David Cournapeau wrote: > On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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 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 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. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] DVCS at PyCon
On Thu, Apr 9, 2009 at 3:04 AM, David Cournapeau 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
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] => 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
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
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
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
On Thu, Apr 9, 2009 at 6:00 AM, Ondrej Certik wrote: > On Wed, Apr 8, 2009 at 11:04 PM, David Cournapeau wrote: >> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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
On Thu, Apr 9, 2009 at 21:09, wrote: > On Thu, Apr 9, 2009 at 6:00 AM, Ondrej Certik wrote: > > On Wed, Apr 8, 2009 at 11:04 PM, David Cournapeau > wrote: > >> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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. > > If you want to do visualized commit in git, try "git citool" ;) -- Cheers, Grissiom ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] DVCS at PyCon
2009/4/9 David Cournapeau : > On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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
On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher wrote: > 2009/4/9 David Cournapeau : >> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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
On Thu, Apr 9, 2009 at 21:38, Matthieu Brucher wrote: > 2009/4/9 David Cournapeau : > > On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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
2009/4/9 David Cournapeau : > On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher > wrote: >> 2009/4/9 David Cournapeau : >>> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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
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
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/OR&R(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
On Thu, Apr 9, 2009 at 7:15 AM, Matthieu Brucher wrote: > 2009/4/9 David Cournapeau : >> On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher >> wrote: >>> 2009/4/9 David Cournapeau : On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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
> 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
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
On Thu, Apr 9, 2009 at 11:16 AM, Andrew Straw 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
>>> 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
On Thu, Apr 9, 2009 at 1:58 PM, Ondrej Certik wrote: > On Thu, Apr 9, 2009 at 7:15 AM, Matthieu Brucher > wrote: >> 2009/4/9 David Cournapeau : >>> On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher >>> wrote: 2009/4/9 David Cournapeau : > On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik 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\copyofpv>git 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
On Fri, Apr 10, 2009 at 5:30 AM, 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\copyofpv>git 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
On Fri, Apr 10, 2009 at 3:56 AM, Matthieu Brucher 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
On Fri, Apr 10, 2009 at 2:29 AM, Christopher Barker 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
On Thu, Apr 9, 2009 at 11:13 PM, David Cournapeau wrote: > On Fri, Apr 10, 2009 at 5:30 AM, 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\copyofpv>git 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
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
On Thu, Apr 9, 2009 at 10:25 PM, David Cournapeau 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
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
On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau 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
On Fri, Apr 10, 2009 at 7:56 AM, 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. I worked like that > with mercurial and I hated it, especially once I started to have ~15 > branches. There are also tools like git-new-workdir (in git's contrib section) that allow you to keep separate working directories for different branches, without needing multiple clones. It's written in shell, but, AFAIK, it works fine on windows using cygwin. yap (yet another porcelain) also provides this functionality. easy-git doesn't, but as a thin layer, it should work fine with git-new-workdir -- Neil Muller drnlmul...@gmail.com I've got a gmail account. Why haven't I become cool? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] DVCS at PyCon
Ondrej Certik wrote: > On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau > 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
On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing wrote: > Ondrej Certik wrote: >> On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau >> 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. > 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. As far as I know mercurial doesn't have interactive rebase. Besides, the default package in Ubuntu Jaunty doesn't even have the (noninteractive) rebase enabled. So I think it will still take quite some (lot?) of time until mercurial has all those tools available by default. > > 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 I never said numpy should move to git because I like 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, it may be possible. 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 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
On Fri, Apr 10, 2009 at 1:07 AM, 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 > 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
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
2009/4/10 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, 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. 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
On Fri, Apr 10, 2009 at 5:13 AM, Matthieu Brucher wrote: > 2009/4/10 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, > > 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
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 m
Re: [Numpy-discussion] DVCS at PyCon
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/OR&R(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
> * 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
On Sat, Apr 11, 2009 at 1:43 AM, Christopher Barker 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
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
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/OR&R(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
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 > wit
Re: [Numpy-discussion] DVCS at PyCon
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
On Fri, Apr 10, 2009 at 5:47 PM, 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. > > "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
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
On Sat, Apr 11, 2009 at 10:30 AM, 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
On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing 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
David Cournapeau wrote: > On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing 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
On Sat, Apr 11, 2009 at 6:16 AM, Eric Firing 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
On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing 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
On Fri, Apr 10, 2009 at 8:17 PM, David Cournapeau wrote: > On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing 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
On Sat, Apr 11, 2009 at 12:37 PM, Charles R Harris wrote: > > > On Fri, Apr 10, 2009 at 8:17 PM, David Cournapeau > wrote: >> >> On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing 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
On Fri, Apr 10, 2009 at 9:49 PM, David Cournapeau wrote: > On Sat, Apr 11, 2009 at 12:37 PM, Charles R Harris > wrote: > > > > > > On Fri, Apr 10, 2009 at 8:17 PM, David Cournapeau > > wrote: > >> > >> On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing > 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
David Cournapeau wrote: > On Sat, Apr 11, 2009 at 6:16 AM, Eric Firing 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
On Sat, Apr 11, 2009 at 1:00 PM, Charles R Harris 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
On Fri, Apr 10, 2009 at 11:25 PM, David Cournapeau wrote: > On Sat, Apr 11, 2009 at 1:00 PM, Charles R Harris > 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
On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote: > On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing 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
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
On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux 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 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
On Sat, Apr 11, 2009 at 6:38 AM, David Cournapeau wrote: > On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux > 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 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
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
On Sat, Apr 11, 2009 at 5:38 AM, David Cournapeau wrote: > On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux > 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 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
On Sun, Apr 12, 2009 at 12:05 AM, Bruce Southey wrote: > On Sat, Apr 11, 2009 at 5:38 AM, David Cournapeau wrote: >> On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux >> 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 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 wrote: > On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing wrote: >> Ondrej Certik wrote: >>> On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau >>> 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. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] DVCS at PyCon
On Sat, Apr 11, 2009 at 11:44 AM, Neal Becker wrote: > Ondrej Certik wrote: > >> On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing wrote: >>> Ondrej Certik wrote: On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau 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
Ondrej Certik wrote: > On Sat, Apr 11, 2009 at 11:44 AM, Neal Becker wrote: >> Ondrej Certik wrote: >> >>> On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing >>> wrote: Ondrej Certik wrote: > On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau > 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
On Sat, Apr 11, 2009 at 2:12 PM, Neal Becker 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
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
2009/4/11 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. > 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
2009/4/12 Charles R Harris : > 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
2009/4/11 Stéfan van der Walt : > 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
On Sat, Apr 11, 2009 at 8:28 PM, Fernando Perez 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
2009/4/12 Fernando Perez :
> 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
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
On Sun, Apr 12, 2009 at 12:58 PM, Ondrej Certik 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
David Cournapeau 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
Hi Martin 2009/4/13 Martin Geisler : > 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
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
On Mon, Apr 13, 2009 at 9:26 AM, Eric Firing 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
On Mon, Apr 13, 2009 at 9:46 AM, David Cournapeau wrote: > On Mon, Apr 13, 2009 at 9:26 AM, Eric Firing 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 I guess this does not work on windows, though 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 wrote: > On Mon, Apr 13, 2009 at 9:46 AM, David Cournapeau wrote: >> On Mon, Apr 13, 2009 at 9:26 AM, Eric Firing 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
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 :) 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 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
On Sun, Apr 12, 2009 at 7:13 PM, David Cournapeau 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
On Sun, Apr 12, 2009 at 10:13 PM, David Cournapeau 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
Stéfan van der Walt writes:
> Hi Martin
>
> 2009/4/13 Martin Geisler :
>> 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"?
Yeah, you can create multiple heads like that. In general, let's say the
current tip of the tree is T:
... --- T
You've just cloned this tree from the Numpy server. To make your head
you will just do a commit:
... --- T --- S
In Mercurial there is no notion of "my head" and "your head" and
(Git-style) branches are just implicitly made from how the changeset
graph develops. So if I have also started from T and made a commit my
tree will look like this:
... --- T --- M
and so far neither of us knows about the other guys branch. We can both
tell that we've done something by using 'hg outgoing', which will tell
you that the S changeset is missing at Numpy, and tell me that the M
changeset is missing.
Now imagine I push my change to Numpy -- if you do 'hg incoming' you'll
see that there is a missing changeset, and if you do 'hg pull' your tree
will end up like this:
S
/
... --- T
\
M
The files in your working copy will still be at the S changeset ('hg
parents' will say S), but you can now see that your changeset has
created a branch with regard to the Numpy repository.
But you can continue working and make U, V, etc:
S --- U --- V
/
... --- T
\
M
In the mean time I might commit N and O to my tree:
... --- T --- M --- N --- O
and push this to Numpy. If you pull from Numpy you'll now see
S --- U --- V
/
... --- T
\
M --- N --- O
At some point you can decide to merge your branch into the main branch
and get a merge changeset X:
S --- U --- V
/ \
... --- T X
\ /
M --- N O
> - Is it possible to remove a head without merging it, discarding the
> children?
Or your can decide to forget about your branch by making a local clone
where you only ask for the O head:
hg clone -r O repo repo-with-O
The new repo-with-O clone will look like this:
... --- T --- M --- N --- O
i.e., it will be exactly like what's on Numpy at this point in time.
The strip command from the mq extension gives an alternative way to do
this from within a single clone:
hg strip -r S
will remove S and all child changesets, i.e., S, U, V and the result
will again be exactly what is on Numpy.
--
Martin Geisler
VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
pgp7HEj6sYYzC.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
2009/4/13 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. The command is git instaweb --httpd=webrick Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
