Git, Mercurial or Bazaar - which do you use most?

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply

Which of the following distributed version control systems do you use the most?

Poll ended at Mon Mar 15, 2010 3:00 pm

Git
48
48%
Mercurial
45
45%
Bazaar
6
6%
 
Total votes: 99

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sinbad » Mon Oct 26, 2009 10:08 am

lf3thn4d wrote:
jacmoe wrote:
lf3thn4d wrote:Whatever the case, no mecurial please. As far as I know, Mecurial doesn't support resume updates.
Of course it does.
If a clone interrupts due to a flaky connection, as simple hg pull will resume it. :)
Hmm.. really? I did seem to have a lot of problems the last time I tried to grab Moz build to test their new JS code. Considering that my connection kept breaking within minutes/seconds, I believe this is indeed an issue. Compared with svn where it's per-file update, mecurial repository takes ages to update. I suspect Git works a lot better here being that they use diff based updates hence file size should be smaller.
Mercurial and Git work almost identically in this respect. Jacmoe's right, a "hg pull" will resume any interrupted clone/pull. Git's repositories do tend to be a bit smaller though, which has been borne out by my conversion tests.
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by jacmoe » Mon Oct 26, 2009 11:49 am

lf3thn4d wrote:
jacmoe wrote:
lf3thn4d wrote:Whatever the case, no mecurial please. As far as I know, Mecurial doesn't support resume updates.
Of course it does.
If a clone interrupts due to a flaky connection, as simple hg pull will resume it. :)

If Sinbad decides on Mercurial, Ogre could offer Mercurial bundles for download, for those unfortunate people with limited net access.
Like Mozilla is doing:
http://www.rumblingedge.com/mozilla-mer ... e-bundles/

So that, my friend, is not an argument. :wink:
Hmm.. really? I did seem to have a lot of problems the last time I tried to grab Moz build to test their new JS code. Considering that my connection kept breaking within minutes/seconds, I believe this is indeed an issue.
Maybe you should try the bundles the next time you decide to grab a Moz build?
The Ogre project could offer downloadable bundles, which you can treat just like any other resumable download.
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
lf3thn4d
Orc
Posts: 478
Joined: Mon Apr 10, 2006 9:12 pm

Re: Git, Mercurial or Bazaar - which do you use most?

Post by lf3thn4d » Mon Oct 26, 2009 12:16 pm

jacmoe wrote:Maybe you should try the bundles the next time you decide to grab a Moz build?
The Ogre project could offer downloadable bundles, which you can treat just like any other resumable download.
Which is what I actually did. Unfortunately it still took ages for me to do an update. The problem is that doing a hg pull seems to restart from scratch every time the connection breaks halfway on a changeset. That's probably due to some guy who did a huge bulk commit. Dunno, didn't pursue further. Either way, I hope any decision here won't cause me problems with accessing the repository. I would personally favor Git over Mercurial. :)
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sinbad » Mon Oct 26, 2009 4:23 pm

Unfortunately Git is now in danger of ruling itself out since it hasn't been able to convert our Subversion repository without either a) losing a ton of data or b) keeping the data but constantly thinking you've modified files when you haven't. And in addition, when it fails, it's very difficult to figure out why.

Compare this to Mercurial which has not only converted successfully every single time, except when I threw a spanner in the works like such as rsync changing the repo in the middle, but when there is a problem it's really very helpful in identifying why, thanks to the full Python stack trace and useful errors. I even managed to hack on the converter and add an enhancement to the process (convert merge tracking) with relatively little experience. It's a very approachable system internally as well as in its API.

My impression through this process has been that Git is great when it works, which is the vast, vast majority of the time - it vindicated itself to a large extent in my eyes through everyday usage on my fairly small and uncomplicated test repositories (< 500 revisions, 1-2 branches). When it breaks though, God help you. It'll either not give you any useful message at all, or it will give you a 1-line esoteric response, which you'll spend ages trawling through mailing lists full of internal Git information, and the upshot will usually be something non-useful like "don't try to do that then" (convert large repositories with branches intact), or "yeah, should really use Linux and not Windows" (msysGit is 9x slower on bulk operations).

So despite the fact that I have become far more comfortable with Git's occasionally esoteric design choices than I was when I started, the lack of a robust Subversion conversion path for large repositories is a killer. I'm confident that I could be happy in either Git or Mercurial; Mercurial is friendlier on the command line, TortoiseGit is slicker in the GUI, Git's repositories are smaller, Mercurial is easier to extend - they have pros and cons that mostly balance each other out. But crucially Mercurial's Subversion conversion is more robust by a wide margin, and having dug about in its internals a bit I feel more confident in the overall architecture too - all Python, the API is intuitive, it has consistent error reporting and diagnostic behaviour - compared to Git which is very clever, but is more esoteric in structure and built on an association of command-line utils leveraging perl and shell scripting and goodness knows what else (hence why it's not Windows-friendly and needs msys). The behaviour of the two under 'problem' conditions, combined with what they look like under the hood when I go to try to extend them, makes me have considerably more trust in Mercurial than Git, particularly when Windows support is important to me. So right now, Mercurial is my tool of choice.

I still have some more test scenarios to work through, but that's the way things are right now.
0 x

NoT3D
Gnoblar
Posts: 9
Joined: Mon Oct 12, 2009 11:32 am

Re: Git, Mercurial or Bazaar - which do you use most?

Post by NoT3D » Mon Oct 26, 2009 5:05 pm

jacmoe wrote:
lf3thn4d wrote:Whatever the case, no mecurial please. As far as I know, Mecurial doesn't support resume updates.
Of course it does.
If a clone interrupts due to a flaky connection, as simple hg pull will resume it. :)

If Sinbad decides on Mercurial, Ogre could offer Mercurial bundles for download, for those unfortunate people with limited net access.
Like Mozilla is doing:
http://www.rumblingedge.com/mozilla-mer ... e-bundles/

So that, my friend, is not an argument. :wink:
Heh, never had any luck with hg pull after a failed clone :P . It seemed to keep rolling back to the beginning and starts all over again. I spent a whole day trying to get mozilla code that way (this was before they created the bundles), only managed it later when my connection somehow stayed on just long enough to do an entire clone.

At any rate, I prefer git mostly because I found it more natural for me.
Right now trying to import ogre trunk/branches/tags into git (version 1.6.5.1) to see if it works well.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sinbad » Mon Oct 26, 2009 5:11 pm

NoT3D wrote:Right now trying to import ogre trunk/branches/tags into git (version 1.6.5.1) to see if it works well.
Good luck :) I've tried using git svn and svn2git many times in the last few days and the results have been terrible. It's unusable on Windows where I can use the latest version of Git, because the process would take 18 hours even with a local SVN copy, except that it fails part way through. On Linux I have to use Git 1.5.4 and the results are that sometimes it fails explicitly, other times it completes seemingly successfully but changes for the last X years are missing (both branches missing and master changes since several years ago), and other times all the history is there but checking out a branch results in 5-10 random files that it thinks are modified (but which aren't), and git reset --head just leaves them there, meaning you can't checkout again without -f. Someone else on my blog tried it with the latest Git on Linux and svn2git and thought it worked, but since their repo was about the same size as one of my attempts that looked like it worked but in fact was missing a ton of data, I think it was also a bad conversion. In all, pretty awful. Git just doesn't like our repository for some reason.
0 x

NoT3D
Gnoblar
Posts: 9
Joined: Mon Oct 12, 2009 11:32 am

Re: Git, Mercurial or Bazaar - which do you use most?

Post by NoT3D » Mon Oct 26, 2009 6:45 pm

sinbad wrote:
NoT3D wrote:Right now trying to import ogre trunk/branches/tags into git (version 1.6.5.1) to see if it works well.
Good luck :) I've tried using git svn and svn2git many times in the last few days and the results have been terrible. It's unusable on Windows where I can use the latest version of Git, because the process would take 18 hours even with a local SVN copy, except that it fails part way through. On Linux I have to use Git 1.5.4 and the results are that sometimes it fails explicitly, other times it completes seemingly successfully but changes for the last X years are missing (both branches missing and master changes since several years ago), and other times all the history is there but checking out a branch results in 5-10 random files that it thinks are modified (but which aren't), and git reset --head just leaves them there, meaning you can't checkout again without -f. Someone else on my blog tried it with the latest Git on Linux and svn2git and thought it worked, but since their repo was about the same size as one of my attempts that looked like it worked but in fact was missing a ton of data, I think it was also a bad conversion. In all, pretty awful. Git just doesn't like our repository for some reason.
Heh, I seem to be having better luck :D .
I'm using version 1.6.5.2 (on Gentoo linux). Here's what I did:
rsync -Pavz rsync://svn.ogre3d.org/svn/ogre/* $HOME/ogre-svn
git svn clone file://$HOME/ogre-svn -T trunk -b branches -t tags $HOME/ogre-git

After that, I checked the history using git gui. Seems to have history all the way from the cvs import back in July 2002.

Tried a bunch of git checkouts and svn checkouts using trunk=master, tags/v1-0-1=remotes/tags/v1-0-1, branches/v1-6-0=remotes/branches/v1-6-0 and trunk -r10 = master 9b4435282a6248ffabb00e277a030b3354ed8ad4 (which matches the same commit as svn r10), and compared them using meld and diff. Can't find any differences.

Going to try with the --no-metadata option to see if that makes the "remote" branches local.
There's also a patch found at http://github.com/samv/git/commits/svk-merge that adds mergeinfo importing. Seems like a clean patch, will try that after the no-metadata thing.
0 x

NoT3D
Gnoblar
Posts: 9
Joined: Mon Oct 12, 2009 11:32 am

Re: Git, Mercurial or Bazaar - which do you use most?

Post by NoT3D » Mon Oct 26, 2009 7:02 pm

NoT3D wrote: Heh, I seem to be having better luck :D .
I'm using version 1.6.5.2 (on Gentoo linux). Here's what I did:
rsync -Pavz rsync://svn.ogre3d.org/svn/ogre/* $HOME/ogre-svn
git svn clone file://$HOME/ogre-svn -T trunk -b branches -t tags $HOME/ogre-git

After that, I checked the history using git gui. Seems to have history all the way from the cvs import back in July 2002.

Tried a bunch of git checkouts and svn checkouts using trunk=master, tags/v1-0-1=remotes/tags/v1-0-1, branches/v1-6-0=remotes/branches/v1-6-0 and trunk -r10 = master 9b4435282a6248ffabb00e277a030b3354ed8ad4 (which matches the same commit as svn r10), and compared them using meld and diff. Can't find any differences.

Going to try with the --no-metadata option to see if that makes the "remote" branches local.
There's also a patch found at http://github.com/samv/git/commits/svk-merge that adds mergeinfo importing. Seems like a clean patch, will try that after the no-metadata thing.
OK no-metadata didn't do much (I stopped it halfway through since it still generates refs/remotes/blah), it only made the revisions not linked to the original svn repo revisions (so git svn fetch won't work anymore). Going to patch my git-svn perl script and see what happens :D
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sinbad » Mon Oct 26, 2009 7:23 pm

Are all the following branches there?

v1-6
v1-4
soc09-samples
soc09-compositor

It never got far enough for me to ever see those.
0 x

NoT3D
Gnoblar
Posts: 9
Joined: Mon Oct 12, 2009 11:32 am

Re: Git, Mercurial or Bazaar - which do you use most?

Post by NoT3D » Mon Oct 26, 2009 7:39 pm

sinbad wrote:Are all the following branches there?

v1-6
v1-4
soc09-samples
soc09-compositor

It never got far enough for me to ever see those.
this is what I got:

Code: Select all

git branch -a
  master
  remotes/Azathoth
  remotes/Hastur
  remotes/IKsampler
  remotes/PreviewMerge
  remotes/avendor
  remotes/material-unstable
  remotes/resource-unstable
  remotes/soc06-billboardclouds
  remotes/soc06-instancing
  remotes/soc06-rendermonkey
  remotes/soc06-scenemanagement
  remotes/soc06-shadows
  remotes/soc06-xsi
  remotes/soc07-emulation
  remotes/soc07-memory
  remotes/soc08-geomshaders
  remotes/soc08-lod
  remotes/soc08-motionsynth
  remotes/soc09-compositor
  remotes/soc09-samples
  remotes/stateManager
  remotes/tags/Dagon-merged-into-HEAD
  remotes/tags/XSI_1-0-1c
  remotes/tags/arelease
  remotes/tags/b237a
  remotes/tags/lastmerge
  remotes/tags/postEihortGpuParamsChange
  remotes/tags/pre-resource-merge
  remotes/tags/preEihortGpuParamsChange
  remotes/tags/rttaa_done
  remotes/tags/soc06-shadows-merged-into-HEAD
  remotes/tags/soc07-start
  remotes/tags/v0-10-0
  remotes/tags/v0-11-0
  remotes/tags/v0-12-0-merged-into-HEAD
  remotes/tags/v0-12-1
  remotes/tags/v0-12-2
  remotes/tags/v0-12-3
  remotes/tags/v0-13-0
  remotes/tags/v0-13-1
  remotes/tags/v0-13-merged-into-HEAD
  remotes/tags/v0-14-0
  remotes/tags/v0-14-1
  remotes/tags/v0-14-merged-into-HEAD
  remotes/tags/v0-15-0
  remotes/tags/v0-15-1
  remotes/tags/v0-15-2
  remotes/tags/v0-15-merged-into-HEAD
  remotes/tags/v097
  remotes/tags/v099d
  remotes/tags/v099e
  remotes/tags/v099f
  remotes/tags/v1-0-0
  remotes/tags/v1-0-0RC1
  remotes/tags/v1-0-1
  remotes/tags/v1-0-2
  remotes/tags/v1-0-3
  remotes/tags/v1-0-4
  remotes/tags/v1-0-5
  remotes/tags/v1-0-6
  remotes/tags/v1-0-7
  remotes/tags/v1-2-0
  remotes/tags/v1-2-0RC1
  remotes/tags/v1-2-0RC2
  remotes/tags/v1-2-1
  remotes/tags/v1-2-2
  remotes/tags/v1-2-3
  remotes/tags/v1-2-4
  remotes/tags/v1-2-5
  remotes/tags/v1-4-0
  remotes/tags/v1-4-0RC1
  remotes/tags/v1-4-0RC2
  remotes/tags/v1-4-1
  remotes/tags/v1-4-2
  remotes/tags/v1-4-3
  remotes/tags/v1-4-4
  remotes/tags/v1-4-5
  remotes/tags/v1-4-6
  remotes/tags/v1-4-7
  remotes/tags/v1-4-8
  remotes/tags/v1-4-9
  remotes/tags/v1-6-0
  remotes/tags/v1-6-0RC1
  remotes/tags/v1-6-1
  remotes/tags/v1-6-2
  remotes/tags/v1-6-3
  remotes/tags/v1-6-4
  remotes/tags/vbo-unstable-merged-HEAD-fixes
  remotes/trunk
  remotes/unlabeled-1.1.2
  remotes/v0-12-0
  remotes/v0-13
  remotes/v0-14
  remotes/v0-15
  remotes/v1-0
  remotes/v1-2
  remotes/v1-4
  remotes/v1-6
  remotes/vbo-unstable
0 x

PaddyWagon
Halfling
Posts: 94
Joined: Fri Jul 17, 2009 4:39 am

Re: Git, Mercurial or Bazaar - which do you use most?

Post by PaddyWagon » Tue Oct 27, 2009 1:04 am

Hate to break into a serious discussion but this quote instantly reminded me of a coder I used to work with
very clever, but is more esoteric in structure and built on an association of command-line utils leveraging perl and shell scripting and goodness knows what else
accurately describes at least 90% of the output he produced :lol:

And one serious comment: repository conversion processes aside it is supremely important that you have confidence in your tools and if something goes wrong then having confidence in your tool's ability to tell you what and why.
0 x

NoT3D
Gnoblar
Posts: 9
Joined: Mon Oct 12, 2009 11:32 am

Re: Git, Mercurial or Bazaar - which do you use most?

Post by NoT3D » Tue Oct 27, 2009 5:22 am

With the patch to git-svn, merge history is imported, here's the diff against version 1.6.5.2 if anyone is interested:

Code: Select all

--- git-svn.perl	2009-10-26 10:57:33.000000000 +0800
+++ git-svn	2009-10-27 12:24:54.000000000 +0800
@@ -2878,14 +2878,155 @@
 	$author;
 }
 
+sub find_extra_svk_parents {
+	my ($self, $ed, $tickets, $parents) = @_;
+	# aha!  svk:merge property changed...
+	my @tickets = split "\n", $tickets;
+	my @known_parents;
+	for my $ticket ( @tickets ) {
+		my ($uuid, $path, $rev) = split /:/, $ticket;
+		if ( $uuid eq $self->ra_uuid ) {
+			my $url = $self->rewrite_root || $self->{url};
+			my $repos_root = $url;
+			my $branch_from = $path;
+			$branch_from =~ s{^/}{};
+			my $gs = $self->other_gs($repos_root."/".$branch_from, $url,
+						 $branch_from, $rev, $self->{ref_id});
+			#my $gs = other_gs ( $url, $repos_root, $branch_from,
+				#$self->{ref_id} );
+			if ( my $commit = $gs->rev_map_get($rev, $uuid) ) {
+				# wahey!  we found it, but it might be
+				# an old one (!)
+				push @known_parents, $commit;
+			}
+		}
+	}
+	for my $parent ( @known_parents ) {
+		my @cmd = ('rev-list', $parent, map { "^$_" } @$parents );
+		my ($msg_fh, $ctx) = command_output_pipe(@cmd);
+		my $new;
+		while ( <$msg_fh> ) {
+			$new=1;last;
+		}
+		command_close_pipe($msg_fh, $ctx);
+		if ( $new ) {
+			print STDERR "Found merge parent (svk:merge ticket): $parent\n";
+			push @$parents, $parent;
+		}
+	}
+}
+
+# note: this function should only be called if the various dirprops
+# have actually changed
+sub find_extra_svn_parents {
+	my ($self, $ed, $mergeinfo, $parents) = @_;
+	# aha!  svk:merge property changed...
+
+	# We first search for merged tips which are not in our
+	# history.  Then, we figure out which git revisions are in
+	# that tip, but not this revision.  If all of those revisions
+	# are now marked as merge, we can add the tip as a parent.
+	my @merges = split "\n", $mergeinfo;
+	my @merge_tips;
+	my @merged_commit_ranges;
+	my $url = $self->rewrite_root || $self->{url};
+	for my $merge ( @merges ) {
+		my ($source, $revs) = split ":", $merge;
+		my $path = $source;
+		$path =~ s{^/}{};
+		my $gs = Git::SVN->find_by_url($url.$source, $url, $path);
+		if ( !$gs ) {
+			warn "Couldn't find revmap for $url$source\n";
+			next;
+		}
+		my @ranges = split ",", $revs;
+		my ($tip, $tip_commit);
+		# find the tip
+		for my $range ( @ranges ) {
+			my ($bottom, $top) = split "-", $range;
+			$top ||= $bottom;
+			my $bottom_commit =
+				$gs->rev_map_get($bottom, $self->ra_uuid) ||
+				$gs->rev_map_get($bottom+1, $self->ra_uuid);
+			my $top_commit =
+				$gs->rev_map_get($top, $self->ra_uuid);
+
+			unless ($top_commit and $bottom_commit) {
+				warn "W:unknown path/rev in svn:mergeinfo "
+					."dirprop: $source:$range\n";
+				next;
+			}
+
+			push @merged_commit_ranges,
+				"$bottom_commit..$top_commit";
+
+			if ( !defined $tip or $top > $tip ) {
+				$tip = $top;
+				$tip_commit = $top_commit;
+			}
+		}
+		unless (!$tip_commit or
+				grep { $_ eq $tip_commit } @$parents ) {
+			push @merge_tips, $tip_commit;
+		}
+		else {
+			push @merge_tips, undef;
+		}
+	}
+	for my $merge_tip ( @merge_tips ) {
+		my $spec = shift @merges;
+		next unless $merge_tip;
+		my @cmd = ('rev-list', "-1", $merge_tip,
+			   "--not", @$parents );
+		my ($msg_fh, $ctx) = command_output_pipe(@cmd);
+		my $new;
+		while ( <$msg_fh> ) {
+			$new=1;last;
+		}
+		command_close_pipe($msg_fh, $ctx);
+		if ( $new ) {
+			push @cmd, @merged_commit_ranges;
+			my ($msg_fh, $ctx) = command_output_pipe(@cmd);
+			my $unmerged;
+			while ( <$msg_fh> ) {
+				$unmerged=1;last;
+			}
+			command_close_pipe($msg_fh, $ctx);
+			if ( $unmerged ) {
+				warn "W:svn cherry-pick ignored ($spec)\n";
+			}
+			else {
+				warn "Found merge parent (svn:mergeinfo prop): $merge_tip\n";
+				push @$parents, $merge_tip;
+			}
+		}
+	}
+}
+
 sub make_log_entry {
 	my ($self, $rev, $parents, $ed) = @_;
 	my $untracked = $self->get_untracked($ed);
 
+	my @parents = @$parents;
+	my $ps = $ed->{path_strip} || "";
+	for my $path ( grep { m/$ps/ } %{$ed->{dir_prop}} ) {
+		my $props = $ed->{dir_prop}{$path};
+		if ( $props->{"svk:merge"} ) {
+			$self->find_extra_svk_parents
+				($ed, $props->{"svk:merge"}, \@parents);
+		}
+		if ( $props->{"svn:mergeinfo"} ) {
+			$self->find_extra_svn_parents
+				($ed,
+				 $props->{"svn:mergeinfo"},
+				 \@parents);
+		}
+	}
+
 	open my $un, '>>', "$self->{dir}/unhandled.log" or croak $!;
 	print $un "r$rev\n" or croak $!;
 	print $un $_, "\n" foreach @$untracked;
-	my %log_entry = ( parents => $parents || [], revision => $rev,
+	my %log_entry = ( parents => \@parents, revision => $rev,
 	                  log => '');
 
 	my $headrev;
0 x

sryan
Gnoblar
Posts: 12
Joined: Thu Feb 16, 2006 7:06 am

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sryan » Tue Oct 27, 2009 6:40 am

So I voted for git ... yay git ! ( ok, so I might be a fanboy ... who knew ? )

Of the posted I've only used git, however a few practical items I've noticed.

Codebase: 640k lines of code, approximately 10 commit devs ( strictly linux based )

- Cloning is pretty fast, and the repo is not huge

- merging is a dream. If git shines anywhere ( IMO ) it's merging. I've easily had from 10-50 developer branches starting from various points in time, and merged them in less time than I would have thought possible. It remembers merges and conflict resolution to a degree ... so if you merge a conflict once, merging another branch that would cause the same conflict is automatically correctly sorted out. Very handy.

- I like the way it does the conflict resolution ( ala git mergetool ). This is something that is semi achieved through various ways in other SCMs, this seems elegant to me though.

- I also like the idea of cherry picking a commit. The idea of being able to merge in portions of a branch, but not all of it is nice. I know this can be done in many ways, but git seems to make this very easy ( I'd have to check I'm going from memory, but I'm pretty sure that you can also excise a single commit ... ala git revert <hash>)

- one thing I found was that the merge commits often cluttered the history ( there are flags to omit them from listing )

- on the downside, there are some commands that are sometimes ... unclear. Like most people I'm sure I picked up git on the fly because I had to. Let me say that "rebase" didn't do what I thought it was supposed to. I would make sure that the workflow for commit devs is well established, and you decide ahead of time how to deal with issues.

- one thing I found while working on worldforge is that depending on how many commit devs you have the remote branch list can become ... large. This I found becomes a problem when you have people that just "push" the full changes ... the local branches go with it. Worse, when I delete a branch locally AND remotely ... if another commit dev that had previously "fetched" that branch ... just does a "git push" ... the remote branch will reappear. This is not a problem if you very much restrict who can commit. Same goes for tags. One way to get around this is to fold in changes via patch/email submissions ( which git seems to support quite well )

I'm sure there is more, but that's my 0.02
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sinbad » Tue Oct 27, 2009 11:18 am

@Not3D: thanks for the info.

When you git checkout a branch (say v1-6), does everything look ok when you 'git status'? And when you switch again to another branch and back to master? It's probably best if I summarise my results with git conversions:
  • git-svn 1.6.4 on Windows/msysGit w/ original svn repo: crash after 1900 revisions (and projected 18 hour runtime anyway)
  • git-svn 1.5.4 on Linux w/ original svn repo: crash after 176 revisions
  • git-svn 1.5.4 on Linux w/ upgraded svn 1.5 repo: successful completion (1h40 runtime). BUT on checking out any branches a random number of files are marked as modified when they're not, git reset --hard makes no difference and git diff shows nothing, but you can only checkout again using -f
  • svn2git 1.3.1 and git-svn (1.5.4 on my machine and 1.6.3 on someone elses) on Linux with any svn repo (orig or upgraded): completion but missing recent repository history of anything between 2 and 6 years
So you can see why I haven't been at all impressed by Git's SVN conversion, at least for non-trivial repositories. This needs to work reliably and repeatably for me to consider it a valid option. As a last resort just to see if I can get to the stage where I can properly evaluate the Ogre repository on Git, I'm grabbing the latest Kubuntu (I don't like Gnome) which I'll install the latest source version of Git on. Honestly, this is a huge number of hoops for me to have to jump through compared to Mercurial and doesn't reflect well on Git, but I'd still like to at least be able to complete the process for review purposes.
0 x

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel

Re: Git, Mercurial or Bazaar - which do you use most?

Post by Assaf Raman » Tue Oct 27, 2009 3:15 pm

Wow, seems to me like too many hoops.
0 x
Watch out for my OGRE related tweets here.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by jacmoe » Tue Oct 27, 2009 3:53 pm

sryan wrote:that's my 0.02
You two cents means nothing.
Since you've only used Git, I mean. :)
Most of what you said could be said about Mercurial or Bazaar as well.
Except cherry-picking, which can be done with transplant (to some degree) with Mercurial.
As long as you do atomic commits, you really don't need cherry picking. (IMO).
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sinbad » Tue Oct 27, 2009 5:23 pm

I'm reinstalling my one and only Linux desktop machine (or rather, a partition on that machine that I rarely use) with Kubuntu (since I've decided I don't like Gnome) so that I can install a more recent version of Git on Linux to try.

The main reason I'm even considering jumping through all these hoops is that I want to compare how push / pull works with big changesets, and bit lists of changesets, between the two. My current problem with Mercurial is that while I've converted my respository just fine, I haven't so far been able to push it to BitBucket, because I keep getting connection drops. And, it keeps restarting from the beginning, although I think that's because it never gets past the first changeset which is large since it initialises everything. So bizarrely I'm getting the same kind of scalability problems I have with Subversion, which is kind of depressing considering all the time I'm putting into this. I want to see how Git / GitHub / Gitorious compares in this regard.
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by jacmoe » Tue Oct 27, 2009 5:30 pm

Couldn't you just init the repository at the hub, then create a bundle locally, upload the bundle file to the hub and unpack and pull (off the top of my head).
Of course, just rsync'ing the whole repo could also work..
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sinbad » Tue Oct 27, 2009 6:19 pm

jacmoe wrote:Couldn't you just init the repository at the hub, then create a bundle locally, upload the bundle file to the hub and unpack and pull (off the top of my head).
Of course, just rsync'ing the whole repo could also work..
I could, but it's important that whatever system we use can handle large pushes on occasion. Sometimes we make big changes (like the license change), and it has to operate acceptably when we do that. Like I say, one big issue in the last few months with SVN is how unreliable it has got when trying to commit large changes - they might not happen that often, but they do happen and they need to work.
0 x

NoT3D
Gnoblar
Posts: 9
Joined: Mon Oct 12, 2009 11:32 am

Re: Git, Mercurial or Bazaar - which do you use most?

Post by NoT3D » Tue Oct 27, 2009 6:45 pm

sinbad wrote:@Not3D: thanks for the info.

When you git checkout a branch (say v1-6), does everything look ok when you 'git status'? And when you switch again to another branch and back to master? It's probably best if I summarise my results with git conversions:
git status looks fine. Tried it with all the branches.
sinbad wrote:
  • git-svn 1.6.4 on Windows/msysGit w/ original svn repo: crash after 1900 revisions (and projected 18 hour runtime anyway)
  • git-svn 1.5.4 on Linux w/ original svn repo: crash after 176 revisions
  • git-svn 1.5.4 on Linux w/ upgraded svn 1.5 repo: successful completion (1h40 runtime). BUT on checking out any branches a random number of files are marked as modified when they're not, git reset --hard makes no difference and git diff shows nothing, but you can only checkout again using -f
  • svn2git 1.3.1 and git-svn (1.5.4 on my machine and 1.6.3 on someone elses) on Linux with any svn repo (orig or upgraded): completion but missing recent repository history of anything between 2 and 6 years
So you can see why I haven't been at all impressed by Git's SVN conversion, at least for non-trivial repositories. This needs to work reliably and repeatably for me to consider it a valid option. As a last resort just to see if I can get to the stage where I can properly evaluate the Ogre repository on Git, I'm grabbing the latest Kubuntu (I don't like Gnome) which I'll install the latest source version of Git on. Honestly, this is a huge number of hoops for me to have to jump through compared to Mercurial and doesn't reflect well on Git, but I'd still like to at least be able to complete the process for review purposes.
Heh yeah. Well, I've not had issues yet, but I'm not using git 1.5.4 or 1.6.3 though. I'm using 1.6.5.1 with the patch mentioned above.
0 x

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by CABAListic » Tue Oct 27, 2009 6:52 pm

For the fun of it, I just tried to convert the Ogre repository to bzr. Worked reasonably well, as it seems, very fast, too. It finished in about 22 mins and appears to be complete. Of course, since I lack any actual experience with DVCS in general and bzr in particular, I don't really know what to do with it :)
The created repository is very large, though. About 700 Mb, which is twice the size of the original SVN repo. If there is a way to optimise that, I'd speculate it would need about the amount of time which the pure conversion leads over the competitors. :)
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sinbad » Tue Oct 27, 2009 6:58 pm

Yeah, as a comparison Mercurial comes in at 200Mb converted, and Git at about 150Mb - when you can get it to complete anyway, and mine had the weird checkout problems. I started pruning the Mercurial repository of branches I didn't need, but after pruning all the old branches I found I'd ony saved about 7Mb! Not a worthwhile way to spend an hour :? I assume that the majority of the size is coming from trunk media file changes.

It would be useful to be able to drop history for X years ago - for example we could live with only about 3 years history I think, and just archive the rest, if that made a worthwhile difference to the size. However the way that all the DVCSs seem to work appears to make that a hard thing to do, because everything is stored as a delta on top of previous results. I'll have to investigate this more but certainly Mercurial could only strip a revision and its direct dependents (like a branch), not a revision and its anscestors which is what I'd like to do in trunk.
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by Klaim » Tue Oct 27, 2009 7:21 pm

About the big push in BigBucket problem, if the problem is relative to the server, maybe you can try see if it works well with Google Code? Not to advocate that google code is better (I don't know a lot about bitbucket or gcode), but just to concentrate on the Mercurial efficiency rather than trying to fix server timeout problems.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

Re: Git, Mercurial or Bazaar - which do you use most?

Post by sinbad » Tue Oct 27, 2009 7:28 pm

Yeah, possibly. I liked BitBucket because it had fork & merge request functionality, rather than a simple patch list, although now I've used it it's not as slick as Gitorious, there's no tracking of the merge requests or anything like that which I really liked in Gitorious. Functionality like this is another aspect of reviewing these tools, which is why I want to get them up to the repository servers.

On the history collapsing thing, it appears that git has 'rebase with squash' and Mercurial can do something similar with MQ and qfold. However both are typically talked about in the context of combining a small number of commits which you are wanting to submit upstream, not collapsing large amounts of early history. But, I intend to try it. I suspect I'll need to prune off branches originating in the area I want to collapse first too.
0 x

NoT3D
Gnoblar
Posts: 9
Joined: Mon Oct 12, 2009 11:32 am

Re: Git, Mercurial or Bazaar - which do you use most?

Post by NoT3D » Tue Oct 27, 2009 7:58 pm

sinbad wrote:On the history collapsing thing, it appears that git has 'rebase with squash' and Mercurial can do something similar with MQ and qfold. However both are typically talked about in the context of combining a small number of commits which you are wanting to submit upstream, not collapsing large amounts of early history. But, I intend to try it. I suspect I'll need to prune off branches originating in the area I want to collapse first too.
collapsing early history with git can be done with git-filter-branch I think, see the EXAMPLES in:

Code: Select all

git filter-branch --help
0 x

Post Reply