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.lf3thn4d wrote: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.jacmoe wrote:Of course it does.lf3thn4d wrote:Whatever the case, no mecurial please. As far as I know, Mecurial doesn't support resume updates.
If a clone interrupts due to a flaky connection, as simple hg pull will resume it.
Git, Mercurial or Bazaar - which do you use most?
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
Maybe you should try the bundles the next time you decide to grab a Moz build?lf3thn4d wrote: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.jacmoe wrote:Of course it does.lf3thn4d wrote:Whatever the case, no mecurial please. As far as I know, Mecurial doesn't support resume updates.
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.
The Ogre project could offer downloadable bundles, which you can treat just like any other resumable download.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- lf3thn4d
- Orc
- Posts: 478
- Joined: Mon Apr 10, 2006 9:12 pm
- x 12
Re: Git, Mercurial or Bazaar - which do you use most?
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.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.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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.
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.
-
- Gnoblar
- Posts: 9
- Joined: Mon Oct 12, 2009 11:32 am
Re: Git, Mercurial or Bazaar - which do you use most?
Heh, never had any luck with hg pull after a failed clone . 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.jacmoe wrote:Of course it does.lf3thn4d wrote:Whatever the case, no mecurial please. As far as I know, Mecurial doesn't support resume updates.
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.
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.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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.NoT3D wrote:Right now trying to import ogre trunk/branches/tags into git (version 1.6.5.1) to see if it works well.
-
- Gnoblar
- Posts: 9
- Joined: Mon Oct 12, 2009 11:32 am
Re: Git, Mercurial or Bazaar - which do you use most?
Heh, I seem to be having better luck .sinbad wrote: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.NoT3D wrote:Right now trying to import ogre trunk/branches/tags into git (version 1.6.5.1) to see if it works well.
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.
-
- Gnoblar
- Posts: 9
- Joined: Mon Oct 12, 2009 11:32 am
Re: Git, Mercurial or Bazaar - which do you use most?
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 happensNoT3D wrote: Heh, I seem to be having better luck .
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.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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.
v1-6
v1-4
soc09-samples
soc09-compositor
It never got far enough for me to ever see those.
-
- Gnoblar
- Posts: 9
- Joined: Mon Oct 12, 2009 11:32 am
Re: Git, Mercurial or Bazaar - which do you use most?
this is what I got: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.
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
-
- Halfling
- Posts: 94
- Joined: Fri Jul 17, 2009 4:39 am
- x 1
Re: Git, Mercurial or Bazaar - which do you use most?
Hate to break into a serious discussion but this quote instantly reminded me of a coder I used to work with
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.
accurately describes at least 90% of the output he producedvery 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
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.
-
- Gnoblar
- Posts: 9
- Joined: Mon Oct 12, 2009 11:32 am
Re: Git, Mercurial or Bazaar - which do you use most?
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;
-
- Gnoblar
- Posts: 12
- Joined: Thu Feb 16, 2006 7:06 am
Re: Git, Mercurial or Bazaar - which do you use most?
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
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
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
@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:
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
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: Git, Mercurial or Bazaar - which do you use most?
Wow, seems to me like too many hoops.
Watch out for my OGRE related tweets here.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
You two cents means nothing.sryan wrote:that's my 0.02
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).
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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.
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.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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..
Of course, just rsync'ing the whole repo could also work..
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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.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..
-
- Gnoblar
- Posts: 9
- Joined: Mon Oct 12, 2009 11:32 am
Re: Git, Mercurial or Bazaar - which do you use most?
git status looks fine. Tried it with all the branches.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:
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.sinbad wrote: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.
- 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
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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.
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.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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.
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.
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
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.
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.
-
- Gnoblar
- Posts: 9
- Joined: Mon Oct 12, 2009 11:32 am
Re: Git, Mercurial or Bazaar - which do you use most?
collapsing early history with git can be done with git-filter-branch I think, see the EXAMPLES in: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.
Code: Select all
git filter-branch --help