Sorry, I forgot to CC to mailing list
---------- Forwarded message ---------- From: David Douard <david.douard@...400...> Date: 27 févr. 2007 09:06 Subject: Re: [Inkscape-devel] git on win32 To: "Jon A. Cruz" <jon@...18...>
Another solution might me to use Mercurial. It is very similar (in goals and day to day use) to git. It is written in Python. This is the tool we now use at Logilab for all of our projects (for a year now; we used to use CVS).
Mercurial is incredibly fast (git also I guess). And once you have tasted disctributed SCM, well, you just can't imaging how you could have do without it for years...
Seriously, give it a try. Note that the first impression might me disappointing, but once this step is done, what a pleasure... I used to be a big SVN fan (I still find SVN a noce tool, but...), but mercurial (ang git which really is very similar) is an incredible tool for every day work.
This big drawback (for git and mercurial) is the lack of "tortoise" tool on win32 platform.
http://www.selenic.com/mercurial/wiki/
Note also that there is "all-in-one" mercurial package for win32 .
http://mercurial.berkwood.com/
David
2007/2/27, Jon A. Cruz <jon@...18...>:
On Feb 26, 2007, at 1:58 PM, MenTaLguY wrote:
...and however much of cygwin is necessary to make them all work.
-mental
Unfortunately I've found that cygwin makes many things significantly slower.
My other reservation would just be that git was made to solve certain problems that we're not hitting on Inkscape. That point, though, is just something I've not looked into.
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2007-02-27 at 05:50 -0600, Bob Jamison wrote:
David Douard wrote:
This big drawback (for git and mercurial) is the lack of "tortoise" tool on win32 platform.
This would be the biggest one for me. Without Tortoise or its equivalent, any other SCM would be a regression.
I wholeheartedly agree.
Regards, Johan
Bob Jamison wrote:
David Douard wrote:
This big drawback (for git and mercurial) is the lack of "tortoise" tool on win32 platform.
This would be the biggest one for me. Without Tortoise or its equivalent, any other SCM would be a regression.
Indeed. Would a gui satisfy your needs or do you require shell integration?
Aaron
I'd be lost without the shell integration these days. tortoise is just so much more elegant than anything else I've seen.
On 2/27/07, Aaron Spike <aaron@...749...> wrote:
Bob Jamison wrote:
David Douard wrote:
This big drawback (for git and mercurial) is the lack of "tortoise" tool on win32 platform.
This would be the biggest one for me. Without Tortoise or its equivalent, any other SCM would be a regression.
Indeed. Would a gui satisfy your needs or do you require shell integration?
Aaron
john cliff wrote:
I'd be lost without the shell integration these days. tortoise is just so much more elegant than anything else I've seen.
I was thinking about this a bit and it occured to me that quite a few of the commands that I use in tortoisesvn wouldn't make sense in something non-linear like git. Still I'm sure shell integration would be possible. On one of the pages I linked it was mentioned as a plan, but I don't think work has started yet.
Aaron Spike
On Tue, 27 Feb 2007 09:07:57 +0100, "David Douard" <david.douard@...400...> wrote:
Another solution might me to use Mercurial. It is very similar (in goals and day to day use) to git.
Mercurial is nice -- I've been using it on one project where I'm collaborating with people from a company where it is the standard SCM. For a user accustomed to git, it's similar-but-different-enough to be disorienting at first, but I appreciated it once I got comfortable with it.
That said, I am starting to really miss some features from git, including:
- multiple branches in one repository (with recent mercurial, possible, but not nice at all) - not having to type full repository paths all the time for pulls/pushes - grafts
-mental
2007/2/27, MenTaLguY <mental@...3...>:
On Tue, 27 Feb 2007 09:07:57 +0100, "David Douard" <david.douard@...400...> wrote:
Another solution might me to use Mercurial. It is very similar (in goals and day to day use) to git.
Mercurial is nice -- I've been using it on one project where I'm collaborating with people from a company where it is the standard SCM. For a user accustomed to git, it's similar-but-different-enough to be disorienting at first, but I appreciated it once I got comfortable with it.
Isn't it ?
That said, I am starting to really miss some features from git, including:
- multiple branches in one repository (with recent mercurial, possible,
but not nice at all)
I don't really understand what this mean. Could you please precise this point?
- not having to type full repository paths all the time for pulls/pushes
Well, the .hg/hgrc file in your repository have a [paths] section one can fille with stuffs like:
[paths] default-push = /home/src/clients/EDFC/EDFC21 morphine = ssh://morphine/hg/clients/EDFC21 www = /home/logilab/www/extranets/EDFC-OSIRIS/EDFC21
Then I only have to do "hg pull morphine" to get any changeset from my laptop, and "hg push www" to publish my changes on the web server.
- grafts
I do not know exactly how git-gaft works, but there are some tools in Mercurial, like transplant (an extension of hg) that may (at least partly) assert this.
-mental
David
On Wed, 2007-02-28 at 12:44 +0100, David Douard wrote:
- multiple branches in one repository (with recent mercurial, possible, but not nice at all)I don't really understand what this mean. Could you please precise this point?
I often have many different features/patches I'm working on relative to trunk at once. I use "topic branches" to manage these.
With git and Mercurial, there are two ways to handle this: designate separate branches within a single working copy's repository and switch among them, or alternately, make a working copy for each separate task.
Git works well for the first approach, since it maintains branches as independent "head" cursors. Mercurial, on the other hand, implements branches as heads relative to ancestor tags, which breaks if the tagged revision ever becomes a branch point.
Both git and Mercurial try to work efficiently for the second approach, in that (at least on intra-filesystem clones) the history files in the two repositories are hard-linked. Mercurial's repository format means that the link is broken for an entire file's history once a new commit modifies it, so the space savings is quickly lost. Git, on the other hand, never breaks existing shared links because its history files are immutable.
- not having to type full repository paths all the time for pulls/pushesWell, the .hg/hgrc file in your repository have a [paths] section one can fille with stuffs like:
Cool, that's what I was looking for. It'll come in handy.
- graftsI do not know exactly how git-gaft works, but there are some tools in Mercurial, like transplant (an extension of hg) that may (at least partly) assert this.
Well, the main point is to let you pull only a subset of the full history without rewriting it. Grafts require that the history has originally been separated into disconnected chunks; with grafts, you can locally rejoin the segments you're interested in with synthetic ancestry links without having to rewrite any commits. Recent versions of git also support doing shallow (partial) clones, again without necessitating history rewriting.
-mental
participants (6)
-
Aaron Spike -
Bob Jamison -
David Douard -
Johan Engelen -
john cliff -
MenTaLguY