Re: [Inkscape-devel] DVCS Again: end-of-line conversion
On 2008-March-15 , at 08:09 , Peter Moulder wrote:
On Sat, Mar 15, 2008 at 12:21:47AM +0100, jiho wrote:
I'm not sure there's really a need to continue counting points right now. It seems bazaar is the clear winner.
I've been composing the below before the above was posted.
Looking at http://en.wikipedia.org/wiki/Comparison_of_revision_control_software, there is one startling difference among git,hg,bzr: it is stated that bzr cannot do end-of-line conversions, i.e. cannot adapt the end of line characters for text files such that they match the end of line style for the operating system under which it is used. (Status: http://bazaar-vcs.org/LineEndings)
I wonder how much of an issue this is; could it actually be fatal for what is otherwise a very promising alternative? Let's look at how we would address this issue if we were to choose bzr.
OK, let's start counting again then. I removed mercurial since no one really stepped up to give advice on it. Right now it seems that both solution have different flaws. However git ones seems to be just a matter of changing habits (e.g. rely more on the command line, learn a few new commands), while on the other hand bazzar would be more enjoyable to use but has some more "deep" flaws (e.g. line endings and slowness).
-- GIT ---------------------------- + faster: . local commits: <1s vs 4s . push a new branch: instantaneous vs 35 min + ability to follow chunk of codes around, without relying on file names. Probably useful from a refactoring point of view + probably the fastest growing user base => many tools + TextMate bundle
- git is designed with the Linux kernel's hierarchical workflow in mind (few 'push'ers to the central repos), so may require alteration in how Inkscape's workflow works (any dev can commit) - we would need to set up and administer this ourselves - revisions are indicated with SHA's rather than numbers - commands dissimilar to what we're used to with svn (e.g., no 'git update') - have to git add all modified files before committing them (or resort to a non specific commit -a) - no decent GUI (for windows?)
-- BZR ---------------------------- + already integrated in launchpad http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.h... . Associating branches to bugs . Associating branches to blueprints . Changes state of bugs in LP when committing in Bazaar . Web interface for creating branches quickly and easily + supports renames (could be considered a - by git users) + supports bundling changesets + tortoiseBZR + Fewer commands - makes it easier to learn + Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows) + Easy administration. Mostly done through Launchpad, plus Bzr folks are available to help.
- no support for line-endings conversion/convention enforcing (but such systems may create the risk of wrongly recognizing binary files)
JiHO --- http://jo.irisson.free.fr/
Well, for a thread that's only 3 days old...
I for one use Mercurial on a daily basis, and think that it's wonderful. :-)
bob
On Sat, Mar 15, 2008 at 12:21:47AM +0100, jiho wrote:
I'm not sure there's really a need to continue counting points right
On 2008-March-16 , at 17:54 , Bob Jamison wrote:
Well, for a thread that's only 3 days old...
I for one use Mercurial on a daily basis, and think that it's wonderful. :-)
Great! could you please add some + (and maybe also - ) in the list below for mercurial then?
I concluded this a bit fast indeed. But even in three days there were already so many messages in favour of bzr that it looked hopeless for anything else to catch up. It seems things in fact more balanced right now.
-- GIT ---------------------------- + faster: . local commits: <1s vs 4s . push a new branch: instantaneous vs 35 min + ability to follow chunk of codes around, without relying on file names. Probably useful from a refactoring point of view + probably the fastest growing user base => many tools + TextMate bundle
- git is designed with the Linux kernel's hierarchical workflow in mind (few 'push'ers to the central repos), so may require alteration in how Inkscape's workflow works (any dev can commit) - we would need to set up and administer this ourselves - revisions are indicated with SHA's rather than numbers - commands dissimilar to what we're used to with svn (e.g., no 'git update') - have to git add all modified files before committing them (or resort to a non specific commit -a) - no decent GUI (for windows?)
-- HG ----------------------------- + tortoiseHG + TextMate bundle
-- BZR ---------------------------- + already integrated in launchpad http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.h... . Associating branches to bugs . Associating branches to blueprints . Changes state of bugs in LP when committing in Bazaar . Web interface for creating branches quickly and easily + supports renames (could be considered a - by git users) + supports bundling changesets + tortoiseBZR + Fewer commands - makes it easier to learn + Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows) + Easy administration. Mostly done through Launchpad, plus Bzr folks are available to help.
- no support for line-endings conversion/convention enforcing (but such systems may create the risk of wrongly recognizing binary files)
JiHO --- http://jo.irisson.free.fr/
jiho wrote:
On 2008-March-16 , at 17:54 , Bob Jamison wrote:
Well, for a thread that's only 3 days old...
I for one use Mercurial on a daily basis, and think that it's wonderful. :-)
Great! could you please add some + (and maybe also - ) in the list below for mercurial then?
I concluded this a bit fast indeed. But even in three days there were already so many messages in favour of bzr that it looked hopeless for anything else to catch up. It seems things in fact more balanced right now.
-- GIT ----------------------------
- faster: . local commits: <1s vs 4s . push a new branch: instantaneous vs 35 min
- ability to follow chunk of codes around, without relying on file
names. Probably useful from a refactoring point of view
- probably the fastest growing user base => many tools
- TextMate bundle
- git is designed with the Linux kernel's hierarchical workflow in
mind (few 'push'ers to the central repos), so may require alteration in how Inkscape's workflow works (any dev can commit)
- we would need to set up and administer this ourselves
- revisions are indicated with SHA's rather than numbers
- commands dissimilar to what we're used to with svn (e.g., no 'git
update')
- have to git add all modified files before committing them (or resort
to a non specific commit -a)
- no decent GUI (for windows?)
-- HG -----------------------------
- tortoiseHG
- TextMate bundle
-- BZR ----------------------------
- already integrated in launchpad http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.h... . Associating branches to bugs . Associating branches to blueprints . Changes state of bugs in LP when committing in Bazaar . Web interface for creating branches quickly and easily
- supports renames (could be considered a - by git users)
- supports bundling changesets
- tortoiseBZR
- Fewer commands - makes it easier to learn
- Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows)
- Easy administration. Mostly done through Launchpad, plus Bzr folks
are available to help.
- no support for line-endings conversion/convention enforcing (but
such systems may create the risk of wrongly recognizing binary files)
Now that some other significant open source projects are using DVCS - maybe it would be good to get an opinion from each as to how they like it. Mercurial(hg) - mozilla Git - linux kernel team Bzr - canonical, webpy I'm sure there are other projects for each.
Also, maybe DVCS can help allow more testing on commits - frequent commits to local machine does not have to be slowed with extensive tests but less frequent merges can have more time consuming tests run on the commits which can help eliminate break the build commit errors, especially on other OS's than the person committing is on.
attached is some feedback from webpy (bzr)
Anand Chitipothu wrote:
On Sun, Mar 16, 2008 at 3:26 PM, MilesTogoe <miles.togoe@...400...> wrote:
The Inkscape team is evaluating using a dvcs. Noticed the webpy development branch is using Bazaar for version control - is everyone happy with it ? is checkout and merging speed okay ?
I am happy with it because
- it is intutive
- good launchpad integration
- easy to host
I have used mercurial, but I don't like its way of managing branches. It keeps all branches in the same tree, whereas bzr keeps each branch in a separate tree, which I found very convenient.
But the speed is a bit disappointing. If you want speed, try git.
On Mon, Mar 17, 2008 at 02:41:20AM -0600, MilesTogoe wrote:
Now that some other significant open source projects are using DVCS - maybe it would be good to get an opinion from each as to how they like it. Mercurial(hg) - mozilla Git - linux kernel team Bzr - canonical, webpy I'm sure there are other projects for each.
According to http://en.wikipedia.org/wiki/Comparison_of_revision_control_software, some users are:
bzr: Ubuntu, Launchpad, Drupal (but for main repository CVS still used), KatchTV git: Linux kernel, Cairo, ELinks, Wine, X.Org, XCB, XMMS2, Compiz Fusion, Samba, OLPC core development hg: e2fsprogs, Mozilla, NetBeans, Xine, Xen, OpenJDK, OpenSolaris, wmii, MoinMoin, Linux-HA
Carl Worth of Cairo is sometimes around #inkscape or related channels, so someone could ask him and post the results here. I'll be meeting with someone from Mozilla in about three weeks if that's any help.
Incidentally, other options are for us to make expanded use of git-svn or bzr-svn or the like (with help from existing users), as a way of getting more experience with those, and some of the benefits of a complete switch, while allowing more time either to hear of others' experiences and/or to see if any of the contenders improves to become a clear winner. (I'm not necessarily advocating this, I'm just saying it's an option, and one we can discard whenever we want if we do consciously adopt it.)
pjrm.
participants (4)
-
Bob Jamison -
jiho -
MilesTogoe -
Peter Moulder