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?
Ok thanks.
My Kubuntu 9.04 install with git 1.6.0 and just using git-svn has worked, 180Mb repo and checkouts are fine it seems. So that will be my base for further Git testing, when I get time (this is increasingly eating all my Ogre time!)
My Kubuntu 9.04 install with git 1.6.0 and just using git-svn has worked, 180Mb repo and checkouts are fine it seems. So that will be my base for further Git testing, when I get time (this is increasingly eating all my Ogre time!)
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Git, Mercurial or Bazaar - which do you use most?
Hi,
It's been a while since my last appearance at these forums, but well... I like challenges and git conversion seemed like one so I tried this at home.
I used git 6.5.2 with rsynced ogre svn r9227.
First a definitions for Git object types:
- blob - a untyped file, just a bunch of data with no meaning for git (regular file, diff, etc.)
- tree - named object that references blobs and other trees; it represents a directory
- commit - object, that references a tree and parent commit
- tag - object that references commit
- head - a reference to commit that is a "tip" of branch
What have I found:
1. Conversion went smoothly using these:
The authors-map file maps svn commiter to a git commiter (ie sinbad = Steve Streeting <your@mail.here>). I made it using:
, then looked up commiter names in AUTHORS, sourceforge (see 5.)
EDIT: you'll also need a following entry in authors-map file: - there are commits without svn:author specified (cvs2svn I suppose)
2. There's some very strange "branching anomally" at the beginning of history: 3. SVN Tags are converted as git branches, which makes them "heavy". Git tags are lightweight references to particular commits, so there I tried a convert using command (found with google):
There's one catch with it: it makes tag to commit that created branch. So I modified the last part of above command to read:
That makes tag for commit that is parent to the commit that introduced branch.
There's only one commit that has 2 parents (the one for tag v1-6-0), you can fix it with:
4. I removed branches for "svn tags" simply deleting refs in git repository. Just remove lines referencing ref/remotes/tags/... from .git/packed-refs and remove .git/refs/remotes/tags directory and that's it. You're then left with dangling commits (the commits that are not referenced anyhow) but doing some pruning should make them disappear:
Also note that it's safe to prune a commit with no changes (commit referencing the same tree that other commits)
5. I found some commits by users that weren't referenced in AUTHORS file:
e-r00, miathan6, sience and thebeast13 (these are sf.net logins)
6. The refs change logs (the .git/logs directory) are useless, you can freely remove that
7. I turned "remote" branches into local ones, renaming entries in .git/packed-refs from /refs/remotes/... to /refs/heads and moving files from .git/refs/remotes to .git/refs/heads
8. I removed trunk branch, because it's the same as master branch (you can see in packed-refs file and/or refs directory that trunk and master reference the same commit object
9. I removed .git/svn directory, .git/index file and .git/gitk.cache (that's being created by git-gui), removed svn-remote section from config file, removed properties logallrefupdates and autocrlf from core config file section, switched core.bare config prop to true and renamed the .git directory to ogre3d.git
10. Cleanup avendor anomally:
Then prune (like step 4)
11. Fix v1-6-4 and v1-6-1 tags (they have useless parents):
12. Run
to clean things a little bit more.
13. I haven't done anything for merge tracking, because I don't know where these merges are. But since you (sinbad) have that data, it could be easily reproduced using grafts (.git/info/grafts file); each line in grafts file is formatted like this:
Just put sha1 of commits and their parents there and it's done.
After all of above I have a bare ogre git repository ready to rock. During above process I learned a lot about git and here are some man pages that make it very clear how git works and how to handle the repository: gitrepository-layout, gitcore-tutorial, gittutorial-2 and gittutorial. What I've found to work is:
- you can edit, add and remove refs by hand with little or no harm at all (be sure to backup converted repo, since it takes some time to convert)
- an accessible commit is a commit that can be tracked down from one of heads or tags (commit is an object, that has among others a parent property, which points another commit, until the beginning of history is reached - that is a commit without a parent); for unreferenced commits they are removed during pruning, so if you want to remove a branch just remove a head of it and prune
- the repository is a simple structure of commits connected with each other, which reference trees (= directories), which reference other trees (= subdirs) and blobs (= files); there's also a tag object (for annotated tags) which reference commit; branching is done just having 2 commits pointing at the same parent
- git is really simple once you get to know it
EDIT: the v1-6-0 tag is a retagging, that's why it has 2 parents, so that's easy to fix:
EDIT2: better pruning, avendor removal (step 10) and some cleanup
EDIT3: super-duper pruning
It's been a while since my last appearance at these forums, but well... I like challenges and git conversion seemed like one so I tried this at home.
I used git 6.5.2 with rsynced ogre svn r9227.
First a definitions for Git object types:
- blob - a untyped file, just a bunch of data with no meaning for git (regular file, diff, etc.)
- tree - named object that references blobs and other trees; it represents a directory
- commit - object, that references a tree and parent commit
- tag - object that references commit
- head - a reference to commit that is a "tip" of branch
What have I found:
1. Conversion went smoothly using these:
Code: Select all
git svn init --no-metadata -s $OGRE_SVN $OGRE_GIT
git svn fetch -A authors-map $OGRE_GIT
Code: Select all
svn log $OGRE_SVN | sed -ne 's/^r[^|]*| \([^ ]*\) |.*$/\1 = \1 <\1@users.sourceforge.net>/p' | sort -u > authors-map
EDIT: you'll also need a following entry in authors-map file:
Code: Select all
(no author) = no author <noauthor@nohost.nodomain>
2. There's some very strange "branching anomally" at the beginning of history: 3. SVN Tags are converted as git branches, which makes them "heavy". Git tags are lightweight references to particular commits, so there I tried a convert using command (found with google):
Code: Select all
git for-each-ref --format="%(refname)" refs/remotes/tags/ | while read tag; do GIT_COMMITTER_DATE="$(git log -1 --pretty=format:"%ad" "$tag")" GIT_COMMITTER_EMAIL="$(git log -1 --pretty=format:"%ce" "$tag")" GIT_COMMITTER_NAME="$(git log -1 --pretty=format:"%cn" "$tag")" git tag ${tag#refs/remotes/tags/} "$tag"; done
Code: Select all
git tag ${tag#refs/remotes/tags/} $(git log -1 --pretty=format:"%P" "$tag")
There's only one commit that has 2 parents (the one for tag v1-6-0), you can fix it with:
Code: Select all
git tag v1-6-0 <sha1 of commit with comment "Manual update">
Code: Select all
git reflog expire --expire=now --all
git repack -ad
git prune
git fsck --full --strict # to make sure there's no dangling objects
5. I found some commits by users that weren't referenced in AUTHORS file:
e-r00, miathan6, sience and thebeast13 (these are sf.net logins)
6. The refs change logs (the .git/logs directory) are useless, you can freely remove that
7. I turned "remote" branches into local ones, renaming entries in .git/packed-refs from /refs/remotes/... to /refs/heads and moving files from .git/refs/remotes to .git/refs/heads
8. I removed trunk branch, because it's the same as master branch (you can see in packed-refs file and/or refs directory that trunk and master reference the same commit object
9. I removed .git/svn directory, .git/index file and .git/gitk.cache (that's being created by git-gui), removed svn-remote section from config file, removed properties logallrefupdates and autocrlf from core config file section, switched core.bare config prop to true and renamed the .git directory to ogre3d.git
10. Cleanup avendor anomally:
Code: Select all
git branch -D avendor
git tag -d arelease
11. Fix v1-6-4 and v1-6-1 tags (they have useless parents):
Code: Select all
git tag -f v1-6-4 "$(git log -1 --pretty=format:"%P" v1-6-4)"
git tag -f v1-6-1 "$(git log -1 --pretty=format:"%P" v1-6-1)"
Code: Select all
git gc
13. I haven't done anything for merge tracking, because I don't know where these merges are. But since you (sinbad) have that data, it could be easily reproduced using grafts (.git/info/grafts file); each line in grafts file is formatted like this:
Code: Select all
<commit> <parent> [<parent>+]
After all of above I have a bare ogre git repository ready to rock. During above process I learned a lot about git and here are some man pages that make it very clear how git works and how to handle the repository: gitrepository-layout, gitcore-tutorial, gittutorial-2 and gittutorial. What I've found to work is:
- you can edit, add and remove refs by hand with little or no harm at all (be sure to backup converted repo, since it takes some time to convert)
- an accessible commit is a commit that can be tracked down from one of heads or tags (commit is an object, that has among others a parent property, which points another commit, until the beginning of history is reached - that is a commit without a parent); for unreferenced commits they are removed during pruning, so if you want to remove a branch just remove a head of it and prune
- the repository is a simple structure of commits connected with each other, which reference trees (= directories), which reference other trees (= subdirs) and blobs (= files); there's also a tag object (for annotated tags) which reference commit; branching is done just having 2 commits pointing at the same parent
- git is really simple once you get to know it
EDIT: the v1-6-0 tag is a retagging, that's why it has 2 parents, so that's easy to fix:
EDIT2: better pruning, avendor removal (step 10) and some cleanup
EDIT3: super-duper pruning
Last edited by guyver6 on Wed Oct 28, 2009 2:40 pm, edited 2 times in total.
- 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?
Wow, that's a lot of steps But thanks, that definitely gives me plenty to think about in terms of repo cleanup on the Git side!
The weird branching at the start of the history is down to the CVS -> SVN conversion; CVS always had to have a 'vendor branch' which was the parent of the local HEAD, this was how it managed upstream changes from an original 'vendor' repository (a very primitive, manual form of DVCS!). In Mercurial I just stripped the 'avendor' branch which resulted in a more natural start point.
The weird branching at the start of the history is down to the CVS -> SVN conversion; CVS always had to have a 'vendor branch' which was the parent of the local HEAD, this was how it managed upstream changes from an original 'vendor' repository (a very primitive, manual form of DVCS!). In Mercurial I just stripped the 'avendor' branch which resulted in a more natural start point.
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Git, Mercurial or Bazaar - which do you use most?
I've uploaded my experimental conversion here, so you or others could evaluate git. It's based on r9230
-
- Gnoblar
- Posts: 9
- Joined: Mon Oct 12, 2009 11:32 am
Re: Git, Mercurial or Bazaar - which do you use most?
Just tried using the above patch (on /usr/libexec/git-core/git-svn) with git 1.6.5.2 and svn2git:NoT3D wrote: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;
Code: Select all
svn log file:///$HOME/oge-svn | sed -ne 's/^r[^|]*| \([^ ]*\) |.*$/\1 = \1 <\1@users.sourceforge.net>/p' | sort -u > $HOME/authors-map.txt
echo '(no author) = no author <noauthor@nohost.nodomain>' >> $HOME/authors-map.txt
mkdir $HOME/ogre-svn2git
cd $HOME/ogre-svn2git
svn2git -v --authors $HOME/authors-map.txt --trunk trunk --branches branches --tags tags file://$HOME/ogre-svn
EDIT
to delete remote branches
Code: Select all
git branch -a|fgrep remotes|xargs git filter-branch --commit-filter ''
git fsck --full --strict
git gc
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Git, Mercurial or Bazaar - which do you use most?
@NoT3D: Doing another rsync and running git svn with your patch Let's see if it can fix an Ogre history a little bit more... (I like the sound of "fixing history" )
BTW, using --no-metadata for git svn init doesn't preserve revision number in converted repo (ie. you can't tell that commit c24b739 is r9203). They are added to commit comments if you're not using --no-metadata.
Put it another way: if you remove .git/svn directory and used --no-metadata you can't tell a damn what commit is what revision.
EDIT: @NoT3D: try using plain git svn instead of svn2git. You can do everything that svn2git does using plain bash (look at svn2git source), yet you have better control.
BTW, using --no-metadata for git svn init doesn't preserve revision number in converted repo (ie. you can't tell that commit c24b739 is r9203). They are added to commit comments if you're not using --no-metadata.
Put it another way: if you remove .git/svn directory and used --no-metadata you can't tell a damn what commit is what revision.
EDIT: @NoT3D: try using plain git svn instead of svn2git. You can do everything that svn2git does using plain bash (look at svn2git source), yet you have better control.
- 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?
Appreciate the help guys.
svn2git doesn't work on the Ogre repo - it's been tried by myself and someone on the bleeding edge of git and it just discards tons of history without reporting any errors. The best result so far with was converting up to 2007 and discarding the rest (silently) - that was with the latest stable svn2git direct from their repo and the latest Linux git. I don't trust it one bit.
svn2git doesn't work on the Ogre repo - it's been tried by myself and someone on the bleeding edge of git and it just discards tons of history without reporting any errors. The best result so far with was converting up to 2007 and discarding the rest (silently) - that was with the latest stable svn2git direct from their repo and the latest Linux git. I don't trust it one bit.
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Git, Mercurial or Bazaar - which do you use most?
I thought to myself: "Who's gonna follow these crazy steps I specified? Not someone as busy as Sinbad..."
So I wrote a script to convert Ogre SVN repo to GIT
Usage
You need linux with git 1.6.5.2 (just grab the source, configure && make && make install) and svn 1.5 installed
1. Define OGRE_GIT and OGRE_SVN environmental variables (when OGRE_SVN is not specified it converts from https://svn.ogre3d.org/...):
2. Run the script:
Viola! Have fun
PS. The patch for retrieving merge history did nothing. It reported that it found merges, but they are not recorded in git repository. The only solution there is left for now is grafts file.
PS2. There's authors-map.txt file in that tar, you might want to check it before starting conversion if the names are correct.
So I wrote a script to convert Ogre SVN repo to GIT
Usage
You need linux with git 1.6.5.2 (just grab the source, configure && make && make install) and svn 1.5 installed
1. Define OGRE_GIT and OGRE_SVN environmental variables (when OGRE_SVN is not specified it converts from https://svn.ogre3d.org/...):
Code: Select all
export OGRE_SVN=file:///home/guyver/ogre-svn-rsync
export OGRE_GIT=/home/guyver/ogre-git
Code: Select all
./ogre-svn2git.sh
PS. The patch for retrieving merge history did nothing. It reported that it found merges, but they are not recorded in git repository. The only solution there is left for now is grafts file.
PS2. There's authors-map.txt file in that tar, you might want to check it before starting conversion if the names are correct.
- 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?
Once again, thanks. I'm probably going to shelve my DVCS testing temporarily for a week or two because it's been taking away too much time from coding, but this will help a lot when I come back to it.
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Git, Mercurial or Bazaar - which do you use most?
I came to converting it myself because you stopped working on it - I didn't want to interrupt yousinbad wrote:Once again, thanks. I'm probably going to shelve my DVCS testing temporarily for a week or two because it's been taking away too much time from coding, but this will help a lot when I come back to it.
And I wanted to give Git a chance, seeing that chart on your blog IMHO converting a repo shouldn't count THAT much, since it's one-time operation. I'm still curious about large commits on windows git, merges and other use cases, that you'll want to test with huge repo.
I'll try now to automate Git merge history retrieval and post any findings / recipes here.
- 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?
And I wanted to give Git a chance, seeing that chart on your blog IMHO converting a repo shouldn't count THAT much, since it's one-time operation.
You forget that this unique operation can have a big impact on future operations, as any hole in the history, any wrong information about a branch can lead to future headache.
Any big-repository-with-long-history project manager would ban git for this.
- nikki
- Old One
- Posts: 2730
- Joined: Sat Sep 17, 2005 10:08 am
- Location: San Francisco
- x 13
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
Ok, I'm not adding anything useful to this conversation at all, but: Yay! git!
I love git and GitHub for the exact same reasons as in betajaen's post.\
Maybe I could make own additions to Ogre and give pull requests now. No need to mess around with patches.
I love git and GitHub for the exact same reasons as in betajaen's post.\
Maybe I could make own additions to Ogre and give pull requests now. No need to mess around with patches.
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Git, Mercurial or Bazaar - which do you use most?
Well, I find git very flexible if it comes to correcting history . And Sinbad already mentioned he may want to drop some of it because of repo size (it's 110 MB to clone for Git, 200 MB for Mercurial). And I wouldn't worry that much about missing information (it can't be wrong if the conversion works correctly, see the avendor anomally, which is IMHO correctly converted very strange piece of history), since I can't see anything wrong that might come out of that. Say you forget to convert a branch merge that happened 2 years ago... It doesn't matter, because you won't merge that branch again, and that's the only reason you'd like to tell Git about it. Actually as I can see that Git repo it could use some cleanup (like pruning unused branches, ie vbo-unstable, or the like). This would further reduce repository size.Klaim wrote:You forget that this unique operation can have a big impact on future operations, as any hole in the history, any wrong information about a branch can lead to future headache.
Any big-repository-with-long-history project manager would ban git for this.
BTW dropping history, I couldn't find a git-way to do this with Git repository, instead when invoking "git svn fetch" you can specify which revisions you want and that way collapse history.
And when I said that converting repo shouldn't count that much I was refering the drop in appreciation of Git because of issues with converting the repository, and that it shouldn't affect the conclusion of which one is better (Hg or Git), because conclusion should be made based on every-day use cases, not a step you do once. I'm helping with conversion, not evaluation
- 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?
Well, I don't care myself about that in fact, I juste say that a lot of project manager would see that as a big bad point.
For me killing old revisions wouldn't hurt.
For me killing old revisions wouldn't hurt.
- 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?
The issue is killing the right versions. We need about 3 years history, with branches intact, just because we're a long-running project and people are still using old versions, and sometimes a bug is only discovered in a transition from an earlier version to a newer version. If you're missing the history, you can't bisect it to figure out when things started deviating, and you can't patch a production project that is based on an earlier version. So it really isn't just about tracking merges, and not caring about history is a very developer-centric stance. In a long-running project there are many other reasons for wanting history intact, at least back to a certain point, because this thing is in the wild, in many, many permutations. My problem with Git is that a) the conversion regularly failed - so far it only works on Git 1.6+ on Linux, everywhere else it fails, which isn't good for confidence and b) svn2git actually silently removed the most recent history, which is the worst possible outcome. So on a qualitative scale, Git ranks considerably below Mercurial for this task. The question is a) whether there's a way to make it work anyway, even if it requires very specific versions / platforms, and b) whether other Git factors - such as efficiency under load - outweigh the initial inconvenience and the lack of trust the problems I had with the conversion have created.
For what it's worth, Git's source build is not very well set up. Their ./configure doesn't pick up any missing dependencies, the compile just fails later on. Come on guys, you're supposed to be good at this sort of thing
For what it's worth, Git's source build is not very well set up. Their ./configure doesn't pick up any missing dependencies, the compile just fails later on. Come on guys, you're supposed to be good at this sort of thing
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Git, Mercurial or Bazaar - which do you use most?
I just spent 20 mins typing here a reply and guess what? Friendliness of that %$!@#$#!$@# VISTA decided that it has to install so-so much important updates to that flawed system and gone to reboot without further notice. Just bah - close Firefox and all other programs... I hate windows so much more now... Why these M$ guys appear not to learn anything from anyone? Mac OS X? Linux? Who's seen any of these restart to apply some crappy updates without asking a user?
EDIT: Trying to reproduce the thoughts is useless as of now, so in short what I was trying to say:
- You have a point to that ./configure in Git - that's probably the heritage of haste in which Git was born (2 months of Linus work, full history here). If there's enough contributors there might be native windows builds of Git, it just has to gain a little more momentum (anyone interested in supporting git for windows? ).
- Git conversion process worked flawlessly on Linux (using the recipe above) and the converted repo is perfectly usable on msysGit
- Cutting revisions before Ogre 1.0 or just prune feature branches. 100 MB to clone ain't that much these days, and it's one-time process anyway
EDIT: Trying to reproduce the thoughts is useless as of now, so in short what I was trying to say:
- You have a point to that ./configure in Git - that's probably the heritage of haste in which Git was born (2 months of Linus work, full history here). If there's enough contributors there might be native windows builds of Git, it just has to gain a little more momentum (anyone interested in supporting git for windows? ).
- Git conversion process worked flawlessly on Linux (using the recipe above) and the converted repo is perfectly usable on msysGit
- Cutting revisions before Ogre 1.0 or just prune feature branches. 100 MB to clone ain't that much these days, and it's one-time process anyway
- 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?
Actually, just tell Vista to delay the reboot. I always tell it to reboot in 4 hours. It's easy enough, actually.guyver6 wrote:Just bah - close Firefox and all other programs... I hate windows so much more now... Why these M$ guys appear not to learn anything from anyone? Mac OS X? Linux? Who's seen any of these restart to apply some crappy updates without asking a user?
Oh - I am shivering from anticipation.guyver6 wrote:- You have a point to that ./configure in Git - that's probably the heritage of haste in which Git was born (2 months of Linus work, full history here). If there's enough contributors there might be native windows builds of Git, it just has to gain a little more momentum (anyone interested in supporting git for windows? ).
The big problem with Git is that it really hasn't moved much further away from being Linus' hastily put together set of repo tools targeting only Linux.
Cross platform-ness wasn't a priority at all.
And the Git community still has that hostile, elitist attitude - no wonder no-one is interested in taking on that task.
/* 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.
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Git, Mercurial or Bazaar - which do you use most?
I did tell to delay the reboot. It was something like "not now" or else... I didn't thought it will reboot after that time without asking a single question!jacmoe wrote:Actually, just tell Vista to delay the reboot. I always tell it to reboot in 4 hours. It's easy enough, actually.
I felt terrorised:
"I told you I'll kill someone 15 minutes from now"
"Please, let's negotiate!"
"No... BANG!!!"
Well that elitism may come from the fact, that there's literally no windows contributions I can see merges of windows-related patches to core Git repository, but there's (as I can remember) one guy making these patches, and these aren't frequent...jacmoe wrote:Oh - I am shivering from anticipation.
The big problem with Git is that it really hasn't moved much further away from being Linus' hastily put together set of repo tools targeting only Linux.
Cross platform-ness wasn't a priority at all.
And the Git community still has that hostile, elitist attitude - no wonder no-one is interested in taking on that task.
Anyway, I don't have a preference of Git over Hg, I just used Git for one commercial project (on Mac OS X platform) and haven't had an opportunity to use Hg yet. I'm helping with Git, because there were guys helping with Hg (BitBucket guys). I want to keep the competition healthy Personally I'd rather see Ogre use Hg - I could take a look at huge Hg-managed project and learn Hg from it.
- stealth977
- Gnoll
- Posts: 638
- Joined: Mon Dec 15, 2008 6:14 pm
- Location: Istanbul, Turkey
- x 42
Re: Git, Mercurial or Bazaar - which do you use most?
I just wanted to share my experience with Hg:
- We rsynced SVN
- We converted it to Hg
- We simply cloned our repository out of it
- Downloaded Tortoise Hg
- Cloned my copy of repository
- Made changes, submitted after a few glitches while trying to learn how it works, i felt quite familiar with it
thats it... No headaches, no manual digging, no history lost, nothing...
NOTES:
1 - Of course our project is much much smaller and had less history (about 1500 commits and few branches)
2 - Jacmoe rocks
3 - I hae no experience with Git, so i may be biased
ismail,
- We rsynced SVN
- We converted it to Hg
- We simply cloned our repository out of it
- Downloaded Tortoise Hg
- Cloned my copy of repository
- Made changes, submitted after a few glitches while trying to learn how it works, i felt quite familiar with it
thats it... No headaches, no manual digging, no history lost, nothing...
NOTES:
1 - Of course our project is much much smaller and had less history (about 1500 commits and few branches)
2 - Jacmoe rocks
3 - I hae no experience with Git, so i may be biased
ismail,
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
-
- Gnoblar
- Posts: 9
- Joined: Mon Oct 12, 2009 11:32 am
Re: Git, Mercurial or Bazaar - which do you use most?
git filter-branch should allow one to drop historyguyver6 wrote: BTW dropping history, I couldn't find a git-way to do this with Git repository, instead when invoking "git svn fetch" you can specify which revisions you want and that way collapse history.
- guyver6
- Greenskin
- Posts: 106
- Joined: Mon Dec 23, 2002 10:16 pm
- Location: Warsaw, Poland
Re: Git, Mercurial or Bazaar - which do you use most?
I tried filter-branch, rebase and reset (with commit --amend) and none worked for me, but I'm a beginner Git user after all, and I surely do not know all tricks, but the "git svn fetch" way does cut the history quite painlessly and there's added value of that - conversion takes less time because of fewer revisions .NoT3D wrote:git filter-branch should allow one to drop historyguyver6 wrote: BTW dropping history, I couldn't find a git-way to do this with Git repository, instead when invoking "git svn fetch" you can specify which revisions you want and that way collapse history.
Git haven't lost Ogre's history for me neither, and all these additional steps are cleanups (all of them are actually fixes to tags; SVN has heavy tags that behave just like branch, Git has lighter tags, that are just pointers to the proper commit; there's a fix for that cvs2svn anomaly that Hg also converts and that's all there is to it).stealth977 wrote:I just wanted to share my experience with Hg:
- We rsynced SVN
- We converted it to Hg
- We simply cloned our repository out of it
- Downloaded Tortoise Hg
- Cloned my copy of repository
- Made changes, submitted after a few glitches while trying to learn how it works, i felt quite familiar with it
thats it... No headaches, no manual digging, no history lost, nothing...
NOTES:
1 - Of course our project is much much smaller and had less history (about 1500 commits and few branches)
2 - Jacmoe rocks
3 - I hae no experience with Git, so i may be biased
ismail,
- 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?
Linux with Git 1.6 and not using svn2git is the way to go with Git conversion. Unfortunately I stumbled through many other combinations which crashed or silently lost history before discovering that, and it means I have to use a specially-installed machine to do the conversion since it doesn't work on Windows and my Linux version is too old. It's a one-off process so it is doable, but it's a confidence thing. When you've tried lots of combinations (msysGit 1.6, Linux Git 1.5, svn2git and various combos) and only one of them works, you can't help but feel it's a bit fragile. And, like I've said what concerns me is that if Git goes wrong, it's not at all friendly about it. Not only did Mercurial's conversion not go wrong unless I basically sabotaged it (unintentionally), when it did go wrong everything was very traceable.guyver6 wrote:Git haven't lost Ogre's history for me neither, and all these additional steps are cleanups (all of them are actually fixes to tags; SVN has heavy tags that behave just like branch, Git has lighter tags, that are just pointers to the proper commit; there's a fix for that cvs2svn anomaly that Hg also converts and that's all there is to it).
The big question is whether post-conversion Git is better at handling large repositories. I've already had issues with getting BitBucket to accept large pushes, so I want to see how GitHub / Gitorious behave. It's no use if I have the same problems with large pushes as I do now ith large commits in SVN, because at least with SVN I can break them up on a file/folder basis if need be (awful though that is for transactional consistency), which is impossible in a DVCS.
- typist
- Kobold
- Posts: 36
- Joined: Mon Apr 02, 2007 3:48 am
- Location: Toronto, Canada
Re: Git, Mercurial or Bazaar - which do you use most?
Hi All,
First I have not used any version control software yet, so take all this with a huge
helping of salt, still what I might have to say might bring a different perspective.
I was recently updating OgreCollada, and downloaded a working copy on Ubuntu (my
primary platform), after a bit I diffed my changes and then began another working
copy on Windows. I was able to update the patch I created on Linux easily through
TortoiseSVN. After I got the Windows port to work the way I wanted, I wanted to go
back to Ubuntu with the new changes, well guess what I could not do this easily
because even though I created the patch I did not have commit access to SF and so my
Ubuntu copy refusing to sync the patch correctly. I got fedup trying to make all of
this to work correctly, till I realized about the concept of distributed version
control.
Distributed version control just made sense. I then started examining each of them
without bias, and what I found was that Mercurial just seemed to be:
- easier to use
- more approachable
- and works the same across OSes.
- has excellent documentation (meaning a nice book) that anyone can read and download
The biggest stumbling block for Git, according to me, is that it is:
- bewilderingly complicated, yes yes I know it offers a natural upgrade from
Subversion but it was scary for me to understand.
- works excellent over Linux, but Windows needs cygwin or other packages. Here is a
quote from the installation for msysgit
Git for Windows is not as stable as Git for anything else.
Actually I stopped playing around with git after that, because I wanted a
distributed VS that was seamlessly cross platform. I understand, however, that OGRE
would need to consider performance issues, etc. So it might make sense for Git, but
as one last pitch for Mercurial, here is what Brian O'Sullivan had to
say about distributed version control.
He is one of the lead authors on Mercurial, so it is naturally pro Mercurial, but he raises very
interesting issues that I thought might make sense to keep in mind when finally deciding.
If you are not happy with the above then remove my one Mercurial vote from the
overall tally.
Best.
First I have not used any version control software yet, so take all this with a huge
helping of salt, still what I might have to say might bring a different perspective.
I was recently updating OgreCollada, and downloaded a working copy on Ubuntu (my
primary platform), after a bit I diffed my changes and then began another working
copy on Windows. I was able to update the patch I created on Linux easily through
TortoiseSVN. After I got the Windows port to work the way I wanted, I wanted to go
back to Ubuntu with the new changes, well guess what I could not do this easily
because even though I created the patch I did not have commit access to SF and so my
Ubuntu copy refusing to sync the patch correctly. I got fedup trying to make all of
this to work correctly, till I realized about the concept of distributed version
control.
Distributed version control just made sense. I then started examining each of them
without bias, and what I found was that Mercurial just seemed to be:
- easier to use
- more approachable
- and works the same across OSes.
- has excellent documentation (meaning a nice book) that anyone can read and download
The biggest stumbling block for Git, according to me, is that it is:
- bewilderingly complicated, yes yes I know it offers a natural upgrade from
Subversion but it was scary for me to understand.
- works excellent over Linux, but Windows needs cygwin or other packages. Here is a
quote from the installation for msysgit
Git for Windows is not as stable as Git for anything else.
Actually I stopped playing around with git after that, because I wanted a
distributed VS that was seamlessly cross platform. I understand, however, that OGRE
would need to consider performance issues, etc. So it might make sense for Git, but
as one last pitch for Mercurial, here is what Brian O'Sullivan had to
say about distributed version control.
He is one of the lead authors on Mercurial, so it is naturally pro Mercurial, but he raises very
interesting issues that I thought might make sense to keep in mind when finally deciding.
If you are not happy with the above then remove my one Mercurial vote from the
overall tally.
Best.
- mkultra333
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 114
Re: Git, Mercurial or Bazaar - which do you use most?
The issues raised in this thread make me wonder if perhaps I'd be better off learning Mercurial rather than Git.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
- nikki
- Old One
- Posts: 2730
- Joined: Sat Sep 17, 2005 10:08 am
- Location: San Francisco
- x 13
- Contact:
Re: Git, Mercurial or Bazaar - which do you use most?
I'm not sure, but the AFAIK (by the last time I read about it), in mercurial you can only make branches by cloning. One feature I love about git in particular is the ability to have local branches. Oh and, rebase.