SCM scorecards

SCM scorecards

[Graeme Gregory]

Moving a private discussion public I started to add a quick score card for SCM's

This is currently how I see feature support.

So far we seem to have this list where goodness is 1-5 (5 being good)

CPU Load Git 5 Monotone 3
Ease of branching Git 5 Monotone 5
Ease of Branch Merging Git 4 Monotone 3
Ease of Serving Git 1 Monotone 5
Ease of Distributed SCM Git 2 Monotone 5


Im sure there is more scores we can add to this list. And you might not 
agree with my scores, but it seems pretty close so far.

Graeme

Re: SCM scorecards

[Michael 'Mickey' Lauer]

Let me add up on that and slightly change:

> CPU Load Git 5 Monotone 3

I think that's rather 5 versus 2

> Ease of Branch Merging Git 4 Monotone 3

Holger?

> Ease of Serving Git 1 Monotone 5

That bad?

> Ease of Distributed SCM Git 2 Monotone 5

Can you expand?

Additionally I want to add:

* 3rd party acceptance Git 5 Monotone 1

Yes, this is not a purely technical argument, however a project that has 
reached a certain size and popularity needs to consider whether the choice of 
a certain SCM scares or attract people.

:M:

-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: SCM scorecards

[Graeme Gregory]

Michael 'Mick
>> Ease of Serving Git 1 Monotone 5
>>     
>
> That bad?
>
>   
Well git supports no serving natively, so you have to decide which
tool you use. And if you want write access then decide infrastrucure
stuff. Compared to mtn serve thats quite complex.
>> Ease of Distributed SCM Git 2 Monotone 5
>>     
>
> Can you expand?
>   
Yes, mtn is designed to have many repos which are mirrors. From my
looks at git it is designed to always end up with one central repo.

The methods of syncing two git trees seem to be hacks or alter
data. master becomes origin/master for example.

And because you always have to pull before push, people cant
use upstreams in parrallel and the tool just works.

I might have missed a trick with git but that is my impression.

> Additionally I want to add:
>
> * 3rd party acceptance Git 5 Monotone 1
>
>   
This is a valid point.

Graeme

Re: SCM scorecards

[Holger Freyther]

On Thursday 27 March 2008 02:01:20 Graeme Gregory wrote:

> Yes, mtn is designed to have many repos which are mirrors. From my
> looks at git it is designed to always end up with one central repo.
>
> The methods of syncing two git trees seem to be hacks or alter
> data. master becomes origin/master for example.

repo.or.cz supports a mirror mode so it can't be too hard. My approach would 
consist out of two shell commands:

	1. git-fetch remote to fetch everything from the remote
	2. git-reset to update the branches to the version of the newly fetched 
	    files.

but then we can ask the provider of repo.or.cz where you can ask it to mirror 
any other git tree how he is implementing it.



>
> And because you always have to pull before push, people cant
> use upstreams in parrallel and the tool just works.

I don't follow here. Creating a branch is the first exception, you push before 
you pull there. If you mean that currently I can push to wolfson and it will 
end up on mtn.oe.org automatically then yes, mtn can do the syncing in a 
fantastic way. And yes with mtn it is more easy due multiple heads. I think 
it is doable with git as well.

Re: SCM scorecards

[Mark Brown]

On Thu, Mar 27, 2008 at 03:11:47AM +0100, Holger Freyther wrote:
> On Thursday 27 March 2008 02:01:20 Graeme Gregory wrote:

> > The methods of syncing two git trees seem to be hacks or alter
> > data. master becomes origin/master for example.

> repo.or.cz supports a mirror mode so it can't be too hard. My approach would 
> consist out of two shell commands:

That's a read-only mirror with one master server where writes happen.
What monotone supports is having multiple masters - users can push
changes to any of the servers and have the servers sort things out.
You'd also have to jump through a small hoop to make all the branches
visible on the child - by default it will not create local branches for
all remote branches, it will represent the remote branches as
remote/branch tags (where remote is the name of the remote, origin by
default).

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: SCM scorecards

[Rod Whitby]

Michael 'Mickey' Lauer wrote:
>> Ease of Serving Git 1 Monotone 5
> 
> That bad?

We should split that into ease of read-only serving, where git gets a 5 
(a http directory is all you need), and ease of read-write serving, 
where 1 is probably a bit harsh (I would say 3, since you need to add 
user accounts with a restricted shell to the Xen instance that you've 
specially set up to run the git server):

http://www.kernel.org/pub/software/scm/git/docs/everyday.html#Repository%20Administration
http://www.itp.tuwien.ac.at/~mattems/blog/2006/07/17#git_server_setup

-- Rod

Re: SCM scorecards

[Holger Freyther]

On Thursday 27 March 2008 01:50:46 Michael 'Mickey' Lauer wrote:
> Let me add up on that and slightly change:
> > Ease of Branch Merging Git 4 Monotone 3
>
> Holger?
That is probably me?

Merging: As Linus pointed out branching is not the problem, merging is:

1.) mtn and git are equally good in doing conflict free merges
2.) merges with conflicts:
	Both git and mtn allow you to use kdiff3, meld.. to do the merge.

	Git is changing files in the workdir but this doesn't matter as you
	resolve the conflict with git-mergetool anyway.

	Git has the concept of the index, which is really cool and makes
	things easy. You can set the file state to anything you want during
	the merge and once you are happy continue.

	Also git is a content tracker, so if I got this right. If I have the same
	bb file (content hash the same, path the same) in two branches mtn
	would go to NCC and refuse to work, git will not have a merge conflict at 
	all.

3.) Things related to merging:
	git-reset HEAD^1 to undo your merge if you didn't like the result (in cases 
where you know you made an accident and disapprove makes little sense)

	git-cherry-pick to pick a change and then pull/rebase without getting a NCC
	conflict.

	git-rebase to change your patchset after some of the patches have been merged
	upstream (effectively what Openmoko is doing on OE).


with git there is little more I could ask for, with mtn I have two unmergable 
things right now. git-rebase is the best thing since sliced bread. So it is 
either a 5:3 or 4:2.


PS: I talk about recent versions of git, with git-mergetool and such...
PPS: I recognize that mtn has served us well, the pace of development is IMHO 
just too slow.

Re: SCM scorecards

[Holger Freyther]

On Thursday 27 March 2008 01:32:29 Graeme Gregory wrote:
> Moving a private discussion public I started to add a quick score card for
> SCM's
>
> This is currently how I see feature support.
>
> So far we seem to have this list where goodness is 1-5 (5 being good)
>
> CPU Load Git 5 Monotone 3
> Ease of branching Git 5 Monotone 5
> Ease of Branch Merging Git 4 Monotone 3
> Ease of Serving Git 1 Monotone 5
> Ease of Distributed SCM Git 2 Monotone 5
>
>
> Im sure there is more scores we can add to this list. And you might not
> agree with my scores, but it seems pretty close so far.

Ease of publishing branches Git 5 Monotone 0:
	Reasoning:
		With git, I push and transfer the number of bytes that I have changed
		to the server. So a small change is a small upload.

		With mtn (0.37 here) in contrast it wants to upload every revision to the 
		server. I'm on a GPRS/UMTS/CDMA line and after ~48MB of upload I got 
		disconnected, twice. The revs still reside on my disk only, I'm not able
		to share it. The database is locked during this operation, I can not do 
		diffs, commits, checkouts during this time.

		Publishing means uploading what we have created, which is a lot bigger than 
		just my small change.


z.

Re: SCM scorecards

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Holger Freyther schreef:
| On Thursday 27 March 2008 01:32:29 Graeme Gregory wrote:
|> Moving a private discussion public I started to add a quick score
card for
|> SCM's
|>
|> This is currently how I see feature support.
|>
|> So far we seem to have this list where goodness is 1-5 (5 being good)
|>
|> CPU Load Git 5 Monotone 3
|> Ease of branching Git 5 Monotone 5
|> Ease of Branch Merging Git 4 Monotone 3
|> Ease of Serving Git 1 Monotone 5
|> Ease of Distributed SCM Git 2 Monotone 5
|>
|>
|> Im sure there is more scores we can add to this list. And you might not
|> agree with my scores, but it seems pretty close so far.
|
| Ease of publishing branches Git 5 Monotone 0:
| 	Reasoning:
| 		With git, I push and transfer the number of bytes that I have changed
| 		to the server. So a small change is a small upload.
|
| 		With mtn (0.37 here) in contrast it wants to upload every revision
to the
| 		server. I'm on a GPRS/UMTS/CDMA line and after ~48MB of upload I got
| 		disconnected, twice. The revs still reside on my disk only, I'm not able
| 		to share it. The database is locked during this operation, I can not do
| 		diffs, commits, checkouts during this time.
|
| 		Publishing means uploading what we have created, which is a lot
bigger than
| 		just my small change.
|

That's because you used the wrong branch include pattern when pushing,
you did:

~  mtn push host org.foo.zecke1

you want:

~  mtn push host org.foo.{original,zecke1}

the second will only transfer new revs, instead of marking all revs with
the new branch cert and (re)transferring them.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH68TeMkyGM64RGpERAkRrAJ9/ZSoJcXU7RZ0SbxFkOipn3UK7uQCffULq
StJJ+msJRiaQLVBwCyR6PEE=
=DX14
-----END PGP SIGNATURE-----

Re: SCM scorecards

[Holger Freyther]

On Thursday 27 March 2008 17:01:34 Koen Kooi wrote:
> Holger Freyther schreef:

> That's because you used the wrong branch include pattern when pushing,
> you did:
>
> ~  mtn push host org.foo.zecke1
>
> you want:

Why would I want to push my changes to the original branch? In this case I 
don't want to because they contain untested changes.

This means I have to pull a 'virgin' org.openmoko.dev tree, pull my branches 
from the other db and publish. Or kill the revisions in the org.openmoko.dev 
branch I don't want to push.


>
> ~  mtn push host org.foo.{original,zecke1}
>
> the second will only transfer new revs, instead of marking all revs with
> the new branch cert and (re)transferring them.

Interesting. I thought the certs say which revision they are attached to, so I 
would have to upload ~25.000 branch certs. The revisions should be unchanged 
and only certs should be uploaded. I assume this is a bug and unnoticed due 
the use of broadband. :)

thanks for the fish-slap, I was able to publish my two branches. So it is not 
zero points on the scoreboard, but I hit one limitiation and one bug or just 
two bugs. I will get my act together and report them.

	z.

Re: SCM scorecards

[Graeme Gregory]

Holger Freyther wrote:
> On Thursday 27 March 2008 01:32:29 Graeme Gregory wrote:
>   
>> Moving a private discussion public I started to add a quick score card for
>> SCM's
>>
>> This is currently how I see feature support.
>>
>> So far we seem to have this list where goodness is 1-5 (5 being good)
>>
>> CPU Load Git 5 Monotone 3
>> Ease of branching Git 5 Monotone 5
>> Ease of Branch Merging Git 4 Monotone 3
>> Ease of Serving Git 1 Monotone 5
>> Ease of Distributed SCM Git 2 Monotone 5
>>
>>
>> Im sure there is more scores we can add to this list. And you might not
>> agree with my scores, but it seems pretty close so far.
>>     
>
> Ease of publishing branches Git 5 Monotone 0:
> 	Reasoning:
> 		With git, I push and transfer the number of bytes that I have changed
> 		to the server. So a small change is a small upload.
>
> 		With mtn (0.37 here) in contrast it wants to upload every revision to the 
> 		server. I'm on a GPRS/UMTS/CDMA line and after ~48MB of upload I got 
> 		disconnected, twice. The revs still reside on my disk only, I'm not able
> 		to share it. The database is locked during this operation, I can not do 
> 		diffs, commits, checkouts during this time.
>
> 		Publishing means uploading what we have created, which is a lot bigger than 
> 		just my small change.
>
>
>   
You experience differs from mine, when I created OM branch I only 
transfered one rev to server.

But I did have to tell it about both branches involved in the sync.

Otherwise the source mtn doesnt know the destination one already
has the revs the branch is based on.

Graeme