Reconsidering the work flow and how the SCM system fits in

Reconsidering the work flow and how the SCM system fits in

[Holger Freyther]

Hey,

I'm anything but happy with the way we work with our repository. We have a 
dreambox branch that is not mergable due issues with our SCM system, the 
OpenMoko guys have to go back to diffing and applying the diff and merging by 
hand, we just commit fundamental changes like sysroot, packaged-staging, RFCs 
in one go and then do weeks of fixing. And I can continue with this list.

What: I think we should use more branches
	- As many shortlived and medium lived branches as developers want
	- Shared branches for stuff like packaged staging, RFCs, sysroot. Were you
	  start the development, add features, other people will compile their stuff, 
	  other compile and then you rebase and merge!
	- Basicly you develop a feature in a branch until it is ready and not 
	  impacting other things, then you rebase/cleanup, propose it for inclusion 
	  and wait for feedback, then merge.
	- Stable distributions and vendors get their own branch, they can merge, 
	  cherry-pick what ever they want.


The issue:
	- mtn can not merge. Forcing me to manually delete files in one copy to do a 
	  merge is not acceptable.
	- mtn has not the concept of short-lived branches (e.g. deleting their 
	  existence once done), mtn suspend does not work as witnessed by our 
	  automerger.
	- mtn pluck is not making me happy
	- I lack a GUI to easily browse the repository
	- I can not clean up changes before I push them!


I want that we use more branches for development, apply review on them, 
land/merge/push these branches after review, pull peoples changes from other 
hosts, work on perfetch patch series before landing patches. I believe we 
need to deploy this kind of development in OE again and as mtn is the 
obstacle to this kind of development I propose to switch to another SCM 
system that allows us to develop OpenEmbedded the way it should be developed.

My criteria:
	- Should have branches, easy merging, easy merging of merges
	- Branches and merging should be cheap
	- Make it easy to put the OE tree into another SCM and still be able
	  to merge (git-svn and such)
	- A good graphical tool to browse the repository
	- A good and maintained web frontend
	- A good set of builtin tools (e.g. like git-add -i and git-rebase -i)

I think the two options are hg and git, I tend to favor git due the size of 
its community. I want to switch OE to one of these systems by the end of this 
month and start using more branches and creating perfect patch series again.


comments? agreement?

	z.


PS: It is not the speed of mtn, it is the lack of development in areas like 
branches, merging, rebasing, we need to use these in OE!

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Holger Freyther schreef:

| PS: It is not the speed of mtn, it is the lack of development in areas
like
| branches, merging, rebasing, we need to use these in OE!

How many people have actually used a branch when developing OE stuff? I
did for the avr32 work and didn't have any problem, merging back only
took one 'mtn propagate' and a push. Regardless if we should switch or
not, I would like to see some 'evidence' of people trying to use a
branch and fail. Switching tools on a "We haven't actually tried to use
the functions, be we hear they are pretty bad" basis would be a bad
thing. It's the same problem OE is facing with all the buildroot and
denx apologists.

regards,

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

iD8DBQFH1j1ZMkyGM64RGpERAmuJAJ9TC2Uf/n4o3YVuuE0uzzRYwAx9cgCeLTXV
a7y4brDJE8FNzd/W499tZ4U=
=Qul3
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Holger Freyther]

On Tuesday 11 March 2008 09:05:45 Koen Kooi wrote:
> Holger Freyther schreef:
> | PS: It is not the speed of mtn, it is the lack of development in areas
>
> like
>
> | branches, merging, rebasing, we need to use these in OE!
>
> How many people have actually used a branch when developing OE stuff? I
> did for the avr32 work and didn't have any problem, merging back only
> took one 'mtn propagate' and a push. Regardless if we should switch or
> not, I would like to see some 'evidence' of people trying to use a
> branch and fail.

I have been trying to merge the dreambox branch for the last six month. 
Monotone has not allowed me to do this so far. It has gone from just refusing 
the work, to spitting random ids on the console, to spitting filenames 
without path on the console. And no: Deleting/Renaming files before being 
able to merge is not an option, specially because mtn is not showing you all 
conflicts... so in the worse case you need to rename more than one file, 
creating really ugly history and only because mtn is not up to the job.
Also you have witnessed the issue with suspending branches and the automerger 
making them live again... there is enough evidence...

z.

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Holger Freyther schreef:

| Also you have witnessed the issue with suspending branches and the
automerger
| making them live again... there is enough evidence...

That was because the automerger was running an mtn version that didn't
have suspend cert support (0.30, it now is running 0.39). Also, as
maintainer of said automerger I haven't heard *anything* about suspend
certs being used by OE nor about them not working for OE. So I think you
should blame bad communication for this, not the tool. I would have
happily upgraded the automerger if someone had bothered to tell me[1].


Koen


[1] Or sent a mail to the mailinglist!

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

iD8DBQFH1lf2MkyGM64RGpERAihFAKCy9bksXJw3mqt/Z+uSB8bzRt2WLwCePokj
2+eDE9DGIzSiwFjA/9Aha2g=
=CCI5
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Tue, 2008-03-11 at 10:59 +0100, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Holger Freyther schreef:
> 
> | Also you have witnessed the issue with suspending branches and the
> automerger
> | making them live again... there is enough evidence...
> 
> That was because the automerger was running an mtn version that didn't
> have suspend cert support (0.30, it now is running 0.39). Also, as
> maintainer of said automerger I haven't heard *anything* about suspend
> certs being used by OE nor about them not working for OE. So I think you
> should blame bad communication for this, not the tool. I would have
> happily upgraded the automerger if someone had bothered to tell me[1].

We had a situation where some bad changes propagated into OE.dev
accidentally and I took steps to try and revert them. On advice from the
monotone devs, I suspended the current head and tried to move us back to
an older one. As the automerger didn't support them it just resurrected
the suspended branch. It was something that needed to be sorted ASAP
since anyone making a checkout during the "bad head" time would have to
manually change their head. In the end I just merged the heads and
corrupted our history since the damage wasn't as bad as originally
thought.

> [1] Or sent a mail to the mailinglist!

I did, Subject:[oe] Monotone issues, Thu, 31 Jan 2008 23:51:39 +0000

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Esben Haabendal]

Holger Freyther wrote:
> Hey,
>
> I'm anything but happy with the way we work with our repository. We have a 
> dreambox branch that is not mergable due issues with our SCM system, the 
> OpenMoko guys have to go back to diffing and applying the diff and merging by 
> hand, we just commit fundamental changes like sysroot, packaged-staging, RFCs 
> in one go and then do weeks of fixing. And I can continue with this list.
>
> What: I think we should use more branches
> 	- As many shortlived and medium lived branches as developers want
> 	- Shared branches for stuff like packaged staging, RFCs, sysroot. Were you
> 	  start the development, add features, other people will compile their stuff, 
> 	  other compile and then you rebase and merge!
> 	- Basicly you develop a feature in a branch until it is ready and not 
> 	  impacting other things, then you rebase/cleanup, propose it for inclusion 
> 	  and wait for feedback, then merge.
> 	- Stable distributions and vendors get their own branch, they can merge, 
> 	  cherry-pick what ever they want.
>
>
> The issue:
> 	- mtn can not merge. Forcing me to manually delete files in one copy to do a 
> 	  merge is not acceptable.
> 	- mtn has not the concept of short-lived branches (e.g. deleting their 
> 	  existence once done), mtn suspend does not work as witnessed by our 
> 	  automerger.
> 	- mtn pluck is not making me happy
> 	- I lack a GUI to easily browse the repository
> 	- I can not clean up changes before I push them!
>
>
> I want that we use more branches for development, apply review on them, 
> land/merge/push these branches after review, pull peoples changes from other 
> hosts, work on perfetch patch series before landing patches. I believe we 
> need to deploy this kind of development in OE again and as mtn is the 
> obstacle to this kind of development I propose to switch to another SCM 
> system that allows us to develop OpenEmbedded the way it should be developed.
>
> My criteria:
> 	- Should have branches, easy merging, easy merging of merges
> 	- Branches and merging should be cheap
> 	- Make it easy to put the OE tree into another SCM and still be able
> 	  to merge (git-svn and such)
> 	- A good graphical tool to browse the repository
> 	- A good and maintained web frontend
> 	- A good set of builtin tools (e.g. like git-add -i and git-rebase -i)
>
> I think the two options are hg and git, I tend to favor git due the size of 
> its community. I want to switch OE to one of these systems by the end of this 
> month and start using more branches and creating perfect patch series again.
>
>
> comments? agreement?
>   
Without going into the specifics of the SCM tools discussion, I would
just like to say that I would REALLY REALLY love to see branches being
used actively in OE development, especially for feature development
(such as sysroot, packaged-staging, and so on) and for release engineering.

For OE to really reach it's potential we have to be able add even more
features while at the same time delivering stable releases/branches for
distro and product developers to work from.

When Joe-average-embedded-product-developer comes along, shopping for
which embedded Linux tool to use for his embedded product, he really
should be able to checkout a stable version of OE and be able to build a
toolchain and a simple image for all supported targets. And this is
certainly not the situation right now.

/Esben

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 09:47:19 +0100
Esben Haabendal <EsbenHaabendal@gmail.com> wrote:

[]

> > comments? agreement?
> >   
> Without going into the specifics of the SCM tools discussion, I would
> just like to say that I would REALLY REALLY love to see branches being
> used actively in OE development, 

Oh really? Because I would think that loving to see them makes little
sense. It makes sense only to use them. And who will use them?
Because if people wanted to use them, they would do that already.
Actually, people who want, do.

> especially for feature development
> (such as sysroot, packaged-staging, and so on) and for release
> engineering.
> 
> For OE to really reach it's potential we have to be able add even more
> features while at the same time delivering stable releases/branches
> for distro and product developers to work from.
> 
> When Joe-average-embedded-product-developer comes along, shopping for
> which embedded Linux tool to use for his embedded product, he really
> should be able to checkout a stable version of OE and be able to
> build a toolchain and a simple image for all supported targets. And
> this is certainly not the situation right now.

Typical mistake. There's stable branch in OE, and based on the
experience with the previous branches, best-practices change control
procedure was applied to it. Now, based on 2.5 month existence of that
branch, I have following observations:

1. People don't know about that branch.
2. Once made known, people still pretend that there's none, and
continue to complain about stability.
3. Most of the rest of people don't put slightest effort into
maintenance of that branch.
4. Those who try, complain that the change control procedure is ...
complex! But it is only a separate branch + pre-review of changes + "all
changes are merged from main branch" rule of thumb.


Having more branches is not going to help with this at all. 

> 
> /Esben

[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Holger Freyther]

On Tuesday 11 March 2008 10:32:56 Paul Sokolovsky wrote:

> Oh really? Because I would think that loving to see them makes little
> sense. It makes sense only to use them. And who will use them?
> Because if people wanted to use them, they would do that already.
> Actually, people who want, do.

I want to use them, I'm sure others would use them (if there is a good example 
usage), but an unmergable dreambox branch is anything but encouraging. As 
Linus said: Branching is easy, merging is the excercise and mtn is not up to 
merging (of non content conflicts).

z.

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 10:45:11 +0100
Holger Freyther <zecke@selfish.org> wrote:

> On Tuesday 11 March 2008 10:32:56 Paul Sokolovsky wrote:
> 
> > Oh really? Because I would think that loving to see them makes
> > little sense. It makes sense only to use them. And who will use
> > them? Because if people wanted to use them, they would do that
> > already. Actually, people who want, do.
> 
> I want to use them, I'm sure others would use them (if there is a
> good example usage), but an unmergable dreambox branch is anything
> but encouraging. As Linus said: Branching is easy, merging is the
> excercise and mtn is not up to merging (of non content conflicts).

Nice, your argumentation is pretty convincing. I just guess that we're
going to have lots of "I'd love to see branches in OE" votes in this
thread, and I'd just love to see them treated separately from "I need
branches", "I'm ok with using branches for my changes", "Branches are
going to complicate my work, but I might try", and "I hate branches - I
already barely have time to do real work" votes.

> 
> z.
> 
[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Graeme Gregory]

> Nice, your argumentation is pretty convincing. I just guess that we're
> going to have lots of "I'd love to see branches in OE" votes in this
> thread, and I'd just love to see them treated separately from "I need
> branches", "I'm ok with using branches for my changes", "Branches are
> going to complicate my work, but I might try", and "I hate branches -
> I already barely have time to do real work" votes.
> 

I need branches.

I need to be able to have an openmoko branch which follows .dev closely
but has some stuff that hasnt reached QA level required to allow in
.dev yet.

I probably need the openmoko branch to be only served by the openmoko
servers.

What I don't know is how this works with monotone, and I haven't had
time to sit down with the manual and trial it.

Graeme

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Graeme Gregory schreef:
|> Nice, your argumentation is pretty convincing. I just guess that we're
|> going to have lots of "I'd love to see branches in OE" votes in this
|> thread, and I'd just love to see them treated separately from "I need
|> branches", "I'm ok with using branches for my changes", "Branches are
|> going to complicate my work, but I might try", and "I hate branches -
|> I already barely have time to do real work" votes.
|>
|
| I need branches.

Heh, I feel an "told you so" moment coming. The 'frozen revision'
approach could have more easily been a branch with no changes (except
for the branchpoint) that you or John only update (mtn propagate
org.openembedde.dev org.openmoko.lag) when you think .dev is buildable.
And it would also have been a natural place to stash things like your
qtopia stuff.

| I need to be able to have an openmoko branch which follows .dev closely
| but has some stuff that hasnt reached QA level required to allow in
| .dev yet.
|
| I probably need the openmoko branch to be only served by the openmoko
| servers.
|
| What I don't know is how this works with monotone, and I haven't had
| time to sit down with the manual and trial it.

The q&d way:

* create a local diff by editing or adding a file
* commit -b org.openmoko.needmorebru
* checkout the branch into a new dir: mtn co -b org.openmoko.needmorebru
* go wild in that branch
* track .dev: mtn propagate org.openembedded.dev org.openmoko.needmorebru

and once the stuff reached a good QA point:

mtn propagate org.openmoko.needmorebru org.openembedded.dev

That what stelios and I did with the avr32 branch and it works great.
The thing that stops the branch from being unmergable is the regular
propagate from .dev to org.openmoko.needmorebru.

regards,

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

iD8DBQFH1mEPMkyGM64RGpERAkaDAJ0ZptVecmhKw+yLg3/j7I7I9YVo4ACfSpkB
aCJd/THz7BPIHwcH/5Ns2SI=
=m7A8
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Holger Freyther]

On Tuesday 11 March 2008 11:38:07 Koen Kooi wrote:
> Graeme Gregory schreef:


> * track .dev: mtn propagate org.openembedded.dev org.openmoko.needmorebru

Non content conflict. ugh! What to do now?

And this has happened with the dreambox branch and this is why I can't 
encourage anyone to use branches with monotone. Even if there is some kind of 
management issue with whatever branch, the tool should not punish this by not 
being able to manage, it is a tool and it should do what it is meant ot be: 
Allow distributed development, and not being able to merge is defeating this 
purpose.

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Holger Freyther schreef:
| On Tuesday 11 March 2008 11:38:07 Koen Kooi wrote:
|> Graeme Gregory schreef:
|
|
|> * track .dev: mtn propagate org.openembedded.dev org.openmoko.needmorebru
|
| Non content conflict. ugh! What to do now?

Since the delta between the two branches is not more than a few
days/revisions it's easy to find out what happened and move conflict out
of the way in your branch, finish the merge and if needed reapply a diff
needed.

| And this has happened with the dreambox branch and this is why I can't
| encourage anyone to use branches with monotone. Even if there is some
kind of
| management issue with whatever branch, the tool should not punish this
by not
| being able to manage, it is a tool and it should do what it is meant
ot be:
| Allow distributed development, and not being able to merge is
defeating this
| purpose.

The non-content conflict handling is absolutely atrocious in monotone,
and the monotone devs aren't doing anything to make it easier (they
changed the error message to offer some more test) because they never
have such conflicts. Which stinks, because we *do* have them.

With git 1.4 everything is much easier, it just deletes any changes you
made :)

But what I'm trying to get at, and doesn't seem to be getting through,
is that our problems are being caused by people not knowing (and not
wanting to know!) the limitations (quirks/bugs/etc) of the tools they
are using. With monotone we are relatively safe, since short of using
the sqlite3 tool we can't loose data or history when there is a cock-up.
I fear that with other tools that weren't written with data retention in
mind (git) we will lose a big chunk of history every now and then
because someone typed git-quxl instead of git-qux1.

regards,

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

iD8DBQFH1msfMkyGM64RGpERAqWmAJ4yh2rHWEemUYrkaXBnhGYvqHV28QCdHpMx
wbSBUgWj+QNCEIEHudiierY=
=vXv6
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Holger Freyther]

On Tuesday 11 March 2008 12:21:03 Koen Kooi wrote:
> Holger Freyther schreef:
> | On Tuesday 11 March 2008 11:38:07 Koen Kooi wrote:
> |> Graeme Gregory schreef:
> |>
> |>
> |> * track .dev: mtn propagate org.openembedded.dev
> |> org.openmoko.needmorebru
> |
> | Non content conflict. ugh! What to do now?
>
> Since the delta between the two branches is not more than a few
> days/revisions it's easy to find out what happened and move conflict out
> of the way in your branch, finish the merge and if needed reapply a diff
> needed.

You can not make this assumption of few days/revs and even in a few days/revs 
one can create many non content conflicts.
Move the conflict out means:
	-Finding the file with mtn au
	-Moving it on one side of the branch
	-Comitting it
	-Merge again and then are done or back to the first item for each non content 
conflict. This adds artificial history, is complicated and stupid and all my 
monkeys are busy doing stuff so I would have to do this...

I want something were this is easy to do. With git I know it is possible (if 
you know to use git-mergetool....). With mtn it is not hard, it is 
impossible, so I can not use branches with mtn nor encourage anyone to do so. 
Specially with my webkit development in a git you start to love cheap, short 
lived feature branches.


> The non-content conflict handling is absolutely atrocious in monotone,
> and the monotone devs aren't doing anything to make it easier (they
> changed the error message to offer some more test) because they never
> have such conflicts. Which stinks, because we *do* have them.


Small excercise: try to merge .dev with .dreambox with mtn and git, see which 
one is barfing out with non obvious error messages (hint: in this case it is 
mtn)


> But what I'm trying to get at, and doesn't seem to be getting through,
> is that our problems are being caused by people not knowing (and not
> wanting to know!) the limitations (quirks/bugs/etc) of the tools they
> are using. With monotone we are relatively safe, since short of using
> the sqlite3 tool we can't loose data or history when there is a cock-up.
> I fear that with other tools that weren't written with data retention in
> mind (git) we will lose a big chunk of history every now and then
> because someone typed git-quxl instead of git-qux1.

With QtWebKit we had a machine with bad memory, on checkouts certain errors 
started to happen. Know what? They were catched on checkout, we had the 
objects distributed anyway, so the checksums (even if not for crypto) are 
pretty good.

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Holger Freyther schreef:
| On Tuesday 11 March 2008 12:21:03 Koen Kooi wrote:
|> Holger Freyther schreef:
|> | On Tuesday 11 March 2008 11:38:07 Koen Kooi wrote:
|> |> Graeme Gregory schreef:
|> |>
|> |>
|> |> * track .dev: mtn propagate org.openembedded.dev
|> |> org.openmoko.needmorebru
|> |
|> | Non content conflict. ugh! What to do now?
|>
|> Since the delta between the two branches is not more than a few
|> days/revisions it's easy to find out what happened and move conflict out
|> of the way in your branch, finish the merge and if needed reapply a diff
|> needed.
|
| You can not make this assumption of few days/revs and even in a few
days/revs
| one can create many non content conflicts.
| Move the conflict out means:
| 	-Finding the file with mtn au
| 	-Moving it on one side of the branch
| 	-Comitting it
| 	-Merge again and then are done or back to the first item for each non
content
| conflict. This adds artificial history, is complicated and stupid and
all my
| monkeys are busy doing stuff so I would have to do this...
|
| I want something were this is easy to do. With git I know it is
possible (if
| you know to use git-mergetool....). With mtn it is not hard, it is
| impossible, so I can not use branches with mtn nor encourage anyone to
do so.
| Specially with my webkit development in a git you start to love cheap,
short
| lived feature branches.
|
|
|> The non-content conflict handling is absolutely atrocious in monotone,
|> and the monotone devs aren't doing anything to make it easier (they
|> changed the error message to offer some more test) because they never
|> have such conflicts. Which stinks, because we *do* have them.
|
|
| Small excercise: try to merge .dev with .dreambox with mtn and git,
see which
| one is barfing out with non obvious error messages (hint: in this case
it is
| mtn)

Actually, it's git, since you can't store empty directories, and we have
those in OE :)

I see your point and I think we should switch scm, but I also want you
to be aware of the 'cvs idiots' we have in our developer group, that
will break stuff with any DSCM we choose.

And I still for for hg, which every developer has installed already,
since we all tested it in the previous round of SCM discussion, haven't we?

regards,

Koen


|
|
|> But what I'm trying to get at, and doesn't seem to be getting through,
|> is that our problems are being caused by people not knowing (and not
|> wanting to know!) the limitations (quirks/bugs/etc) of the tools they
|> are using. With monotone we are relatively safe, since short of using
|> the sqlite3 tool we can't loose data or history when there is a cock-up.
|> I fear that with other tools that weren't written with data retention in
|> mind (git) we will lose a big chunk of history every now and then
|> because someone typed git-quxl instead of git-qux1.
|
| With QtWebKit we had a machine with bad memory, on checkouts certain
errors
| started to happen. Know what? They were catched on checkout, we had the
| objects distributed anyway, so the checksums (even if not for crypto) are
| pretty good.

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

iD8DBQFH1n1VMkyGM64RGpERAuH4AKCuWvMNTroBxYhK4rNc0/nkY89pmACeOwz1
fTx9mkqgBzQk5kIMvv8Hg1M=
=0xvv
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Florian Boor]

Hi,

Koen Kooi schrieb:
> And I still for for hg, which every developer has installed already,
> since we all tested it in the previous round of SCM discussion, haven't we?

yes we did - that's why I have it installed ;) the main reason not to decide to
move to it was the lack of experience with it and if it is really reliable. In
fact the list of projects using hg is quite impressive by now and I did not
manage to find many people complaining about it.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Reconsidering the work flow and how the SCM system fits in

[John Lee]

On Tue, Mar 11, 2008 at 11:38:07AM +0100, Koen Kooi wrote:
> 
> The q&d way:
> 
> * create a local diff by editing or adding a file
> * commit -b org.openmoko.needmorebru
> * checkout the branch into a new dir: mtn co -b org.openmoko.needmorebru
> * go wild in that branch
> * track .dev: mtn propagate org.openembedded.dev org.openmoko.needmorebru

That's what I'm considering to do now.  But I have the following problem:

> and once the stuff reached a good QA point:
> 
> mtn propagate org.openmoko.needmorebru org.openembedded.dev

Most of the time I cannot do that.  There are stuffs not appropriate
for OE.dev in OM, and I suspect there will always be.  However, I have
to push my fixes upstream.  If I didn't do that and someone else did,
it's unnecessary effort plus I will need to manually merge it next
time I sync.

So, I can only pluck.  However, next time when I propagate from OE.dev
to OM, very likely I will get conflicts.

What we're trying to do is having a branch with local changes but
always following the master branch OE.dev.  I think mtn is not very
satisfying in this situation.


Regards,
John

Re: Reconsidering the work flow and how the SCM system fits in

[Holger Freyther]

On Tuesday 11 March 2008 11:14:33 Graeme Gregory wrote:
> > Nice, your argumentation is pretty convincing. I just guess that we're
> > going to have lots of "I'd love to see branches in OE" votes in this
> > thread, and I'd just love to see them treated separately from "I need
> > branches", "I'm ok with using branches for my changes", "Branches are
> > going to complicate my work, but I might try", and "I hate branches -
> > I already barely have time to do real work" votes.
>
> I need branches.

The way I would do it with git:


- Upstream has a git repository
	- master is what org.openembedded.dev is currently

- Openmoko has a git repository
	- (moko-)master for Openmoko


OpenEmbedded =>  Openmoko
	a) cherry-pick (git-fetch openembedded && git-cherry-pick rev)
	b) merge/pull (git-merge openembedded)

none-automergable conflicts are resolvable with git-mergetool and then use 
kdiff3, meld, whatever and you can ignore that git is playing with the files, 
none of these changes automatically end in your index.


Openmoko => OpenEmbedded
	# Create a short lived submit branch
	git-checkout -b submit-branch origin/master

	# Rebase your changes to sit on top of OpenEmbedded
	git-rebase openembedded/master

	# Now throw away non ready recipes or edit some hunks
	git-rebase -i openembedded/master

	# Check what changed from this branch to the master of openembedded
	git-rev-list openmebedded/master..

	# Or use gitk to browse your changes
	gitk

	# Publish your branch
	git-push origin submit-branch

	# Ask people to review and do changes/rebase

	# Push your branch to OpenEmbedded
	git-push openembedded submit-branch:master

	# Delete your submit-branch (you are done)
	git-push origin :submit-branch

	# Delete your branch locally
	git-checkout master
	git-branch -D submit-branch

	# Merge the upstream into your dev tree. With mtn you would get non content 
	# conflicts here, with git you might need to fire up git-mergetool while 
	# doing the merge but both kdiff3 and meld are clever enough to automatically
	# merge these files.
	git-pull openembedded

Such a work flow helps to make bugfixes immediately available, allows long 
lived branches and is working. And I know this can not be done with mtn, and 
I have no hope this will work within the next two or three month and I know 
git can do the job and that corporate users of OE want that and I want it as 
well (my main motivation).

z.

PS: git-add -i and git-rebase -i really won me over

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Holger Freyther schreef:

| PS: git-add -i and git-rebase -i really won me over

That's the fundamental difference between git and other (D)SCMs: git is
for generating clean patches ready for e-mail, the others are for
recording history. So the real questions are:

- - Are we going to mail around patches, or are we going to pull changes
from (remote) branches directly?

- - Do we want to keep an accurate record of our tries to get things right
or do we want a clean, compact (and technically incomplete) history?

regards,

Koen

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

iD8DBQFH1q8gMkyGM64RGpERAu3kAKCu1egI5CMdAHNQWDYk0nA4W7nxXACfcag3
gDTbF9G9lDlAZirw8TRQP0U=
=PSs/
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Paul Sokolovsky schreef:
| Esben Haabendal <EsbenHaabendal@gmail.com> wrote:

|> For OE to really reach it's potential we have to be able add even more
|> features while at the same time delivering stable releases/branches
|> for distro and product developers to work from.
|>
|> When Joe-average-embedded-product-developer comes along, shopping for
|> which embedded Linux tool to use for his embedded product, he really
|> should be able to checkout a stable version of OE and be able to
|> build a toolchain and a simple image for all supported targets. And
|> this is certainly not the situation right now.
|
| Typical mistake. There's stable branch in OE, and based on the
| experience with the previous branches, best-practices change control
| procedure was applied to it. Now, based on 2.5 month existence of that
| branch, I have following observations:
|
| 1. People don't know about that branch.
| 2. Once made known, people still pretend that there's none, and
| continue to complain about stability.
| 3. Most of the rest of people don't put slightest effort into
| maintenance of that branch.
| 4. Those who try, complain that the change control procedure is ...
| complex! But it is only a separate branch + pre-review of changes + "all
| changes are merged from main branch" rule of thumb.

| Having more branches is not going to help with this at all.

There's a false assumption in the above: not all branches will be stable
branches. They will be more like the avr32 branch stelios and I used, so
people will work on implementing a feature in a branch (e.g. sysroot
support), merge it back (with history!) and forget about that branch.

But I still don't think switching scm will improve our 'branch
situation', I think we'll end up with the same old complaints, but this
time about git/hg instead of mtn. I've seen a flat-out refusal to read
mtn docs from several OE developers, who also are the most vocal about
mtn sucking[1]. If we don't fix that attitude we'll keep switching scms
ad infinitum.

And we really should start using something like
http://www.review-board.org/ to review big changes that are too small
for a branch.

regards,

Koen

[1] incidentally most of those people come from a long period of cvs usage
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH1lacMkyGM64RGpERAhGpAJ48J9TijGjyxxxRwH+lQ1elS4LnMQCfWZxI
Cpdq5wxA0DfSeOp3VqfpTdE=
=foWZ
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Mike (mwester)]

Paul Sokolovsky wrote:
> Hello,
> 
> On Tue, 11 Mar 2008 09:47:19 +0100
> Esben Haabendal <EsbenHaabendal@gmail.com> wrote:
> 
> []
> 
>>> comments? agreement?
>>>   
>> Without going into the specifics of the SCM tools discussion, I would
>> just like to say that I would REALLY REALLY love to see branches being
>> used actively in OE development, 
> 
> Oh really? Because I would think that loving to see them makes little
> sense. It makes sense only to use them. And who will use them?
> Because if people wanted to use them, they would do that already.
> Actually, people who want, do.

Hogwash!  It is true that there are a set of people who do not and will 
not use SCM tools.  However, there are numerous others, right here on 
this list, who have *attempted* to use that abomination known as "mtn" 
and discovered that branching with mtn is easy, but merging anything 
"real" is an absolute nightmare.  I will not go into the specific list, 
but merging with mtn is a "cross your fingers and pray" experience.

This is made worse by the fact that there is no culture around mtn. 
Hence there's no sense of "mtn is goodness" as there is developing 
around git.  That's important.  Perhaps not for you, but for many others 
the community help and wisdom around git that's lacking for mtn is what 
will make using branches practical and make merges sucessful.

>> especially for feature development
>> (such as sysroot, packaged-staging, and so on) and for release
>> engineering.
>>
>> For OE to really reach it's potential we have to be able add even more
>> features while at the same time delivering stable releases/branches
>> for distro and product developers to work from.
>>
>> When Joe-average-embedded-product-developer comes along, shopping for
>> which embedded Linux tool to use for his embedded product, he really
>> should be able to checkout a stable version of OE and be able to
>> build a toolchain and a simple image for all supported targets. And
>> this is certainly not the situation right now.
> 
> Typical mistake. There's stable branch in OE, and based on the
> experience with the previous branches, best-practices change control
> procedure was applied to it. Now, based on 2.5 month existence of that
> branch, I have following observations:
> 
> 1. People don't know about that branch.
> 2. Once made known, people still pretend that there's none, and
> continue to complain about stability.
> 3. Most of the rest of people don't put slightest effort into
> maintenance of that branch.
> 4. Those who try, complain that the change control procedure is ...
> complex! But it is only a separate branch + pre-review of changes + "all
> changes are merged from main branch" rule of thumb.

The issue is *not* the stable branch; the issue is that individual 
developers cannot reasonably go off an work on a branch, merge when they 
are satisified, and expect that it will just work.  This is NOT about 
the stable branch.

> 
> Having more branches is not going to help with this at all. 

Quite wrong!  Unstable broken stuff happens in .dev because developers 
dare not venture into the dark horrors of mtn to make their 
destabilizing changes in isolation on a private branch.

>> /Esben
> 
> []
> 

Mike (mwester)

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Holger Freyther schreef:
| Hey,
|
| I'm anything but happy with the way we work with our repository. We
have a
| dreambox branch that is not mergable due issues with our SCM system, the
| OpenMoko guys have to go back to diffing and applying the diff and
merging by
| hand, we just commit fundamental changes like sysroot,
packaged-staging, RFCs
| in one go and then do weeks of fixing. And I can continue with this list.
|
| What: I think we should use more branches
| 	- As many shortlived and medium lived branches as developers want
| 	- Shared branches for stuff like packaged staging, RFCs, sysroot.
Were you
| 	  start the development, add features, other people will compile
their stuff,
| 	  other compile and then you rebase and merge!
| 	- Basicly you develop a feature in a branch until it is ready and not
| 	  impacting other things, then you rebase/cleanup, propose it for
inclusion
| 	  and wait for feedback, then merge.
| 	- Stable distributions and vendors get their own branch, they can merge,
| 	  cherry-pick what ever they want.
|
|
| The issue:
| 	- mtn can not merge. Forcing me to manually delete files in one copy
to do a
| 	  merge is not acceptable.
| 	- mtn has not the concept of short-lived branches (e.g. deleting their
| 	  existence once done), mtn suspend does not work as witnessed by our
| 	  automerger.
| 	- mtn pluck is not making me happy
| 	- I lack a GUI to easily browse the repository
| 	- I can not clean up changes before I push them!
|
|
| I want that we use more branches for development, apply review on them,
| land/merge/push these branches after review, pull peoples changes from
other
| hosts, work on perfetch patch series before landing patches. I believe we
| need to deploy this kind of development in OE again and as mtn is the
| obstacle to this kind of development I propose to switch to another SCM
| system that allows us to develop OpenEmbedded the way it should be
developed.
|
| My criteria:
| 	- Should have branches, easy merging, easy merging of merges
| 	- Branches and merging should be cheap
| 	- Make it easy to put the OE tree into another SCM and still be able
| 	  to merge (git-svn and such)
| 	- A good graphical tool to browse the repository
| 	- A good and maintained web frontend
| 	- A good set of builtin tools (e.g. like git-add -i and git-rebase -i)
|
| I think the two options are hg and git, I tend to favor git due the
size of
| its community. I want to switch OE to one of these systems by the end
of this
| month and start using more branches and creating perfect patch series
again.

If we switch, my vote would be for hg.

regards,

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

iD8DBQFH1lPIMkyGM64RGpERAutoAJ44F/prApfsKU+QcHzCV5fuGunv/wCgmeg5
HVUPl5aPPXoA62PzychJLJA=
=jz3J
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 08:07:10 +0100
Holger Freyther <zecke@selfish.org> wrote:

> Hey,
> 
> I'm anything but happy with the way we work with our repository. We
> have a dreambox branch that is not mergable due issues with our SCM
> system, the OpenMoko guys have to go back to diffing and applying the
> diff and merging by hand, we just commit fundamental changes like
> sysroot, packaged-staging, RFCs in one go and then do weeks of
> fixing. And I can continue with this list.
> 
> What: I think we should use more branches
> 	- As many shortlived and medium lived branches as developers
> want
> 	- Shared branches for stuff like packaged staging, RFCs,
> sysroot. Were you start the development, add features, other people
> will compile their stuff, other compile and then you rebase and merge!
> 	- Basicly you develop a feature in a branch until it is ready
> and not impacting other things, then you rebase/cleanup, propose it
> for inclusion and wait for feedback, then merge.

These latest 2 sound very nice in "SCM for dummies" book, but work in
real life only if many people are *forced* to do that. Works well in
commercial shops ;-). I doubt that's scalable for an average OpenSource
project.

> 	- Stable distributions and vendors get their own branch, they
> can merge, cherry-pick what ever they want.
> 
> 
> The issue:
> 	- mtn can not merge. Forcing me to manually delete files in
> one copy to do a merge is not acceptable.
> 	- mtn has not the concept of short-lived branches (e.g.
> deleting their existence once done), mtn suspend does not work as
> witnessed by our automerger.
> 	- mtn pluck is not making me happy
> 	- I lack a GUI to easily browse the repository
> 	- I can not clean up changes before I push them!

I kinda agree with these.

> I want that we use more branches for development, apply review on
> them, land/merge/push these branches after review, pull peoples
> changes from other hosts, work on perfetch patch series before
> landing patches. I believe we need to deploy this kind of development
> in OE again and as mtn is the obstacle to this kind of development I
> propose to switch to another SCM system that allows us to develop
> OpenEmbedded the way it should be developed.

I would sound my personal contributing developer's opinion here by
saying that any migration talks may happen only if complete changes
migration is proposed. Losing history is unacceptable. Not being able
to trace changelog beyond bitkeeper migration point is pretty
disabling already.

> 
> My criteria:
> 	- Should have branches, easy merging, easy merging of merges
> 	- Branches and merging should be cheap
> 	- Make it easy to put the OE tree into another SCM and still
> be able to merge (git-svn and such)
> 	- A good graphical tool to browse the repository
> 	- A good and maintained web frontend
> 	- A good set of builtin tools (e.g. like git-add -i and
> git-rebase -i)
> 
> I think the two options are hg and git, I tend to favor git due the
> size of its community. 

git suxx, hg rules ;-D. Well, I yet have to see an SCM which does
merges and cherry-picking properly (recording all merge events,
allowing to merge and recombine in arbitrary order, etc.).

And I have no idea how hg supports rebase and stuff, or used it in git
either. I'm sure they suck at that ;-). Also, good political move for
making choices for diversified community which cannot reach concord is
to select worst choice, not the best - this way noone will feel made
wrong in favor of others ;-). That worked well for me with mtn - I
currently feel much better about it than when I started, and glad that
I was made acquainted with yet another SCM. 

Well, per all abobe reasons, I vote for git too. 

> I want to switch OE to one of these systems by
> the end of this month and start using more branches and creating
> perfect patch series again.

Push it, push it! But with complete history, of course.

> 
> 
> comments? agreement?
> 
> 	z.
> 
> 
> PS: It is not the speed of mtn, it is the lack of development in
> areas like branches, merging, rebasing, we need to use these in OE!


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Holger Freyther]

On Tuesday 11 March 2008 10:52:54 you wrote:

> These latest 2 sound very nice in "SCM for dummies" book, but work in
> real life only if many people are *forced* to do that. Works well in
> commercial shops ;-). I doubt that's scalable for an average OpenSource
> project.

See, we are not average we are special! We don't want to be the 90% where svn 
is enough but use a power tool like mtn (but with working merging).

z.

Re: Reconsidering the work flow and how the SCM system fits in

[Marcin Juszkiewicz]

Dnia Tuesday 11 of March 2008, Holger Freyther napisał:

> I'm anything but happy with the way we work with our repository. We
> have a dreambox branch that is not mergable due issues with our SCM
> system, the OpenMoko guys have to go back to diffing and applying the
> diff and merging by hand, we just commit fundamental changes like
> sysroot, packaged-staging, RFCs in one go and then do weeks of fixing.
> And I can continue with this list.

In short: our SCM situation suxx.

> What: I think we should use more branches
> 	- As many shortlived and medium lived branches as developers want
> 	- Shared branches for stuff like packaged staging, RFCs, sysroot. Were
> you start the development, add features, other people will compile
> their stuff, other compile and then you rebase and merge!
> 	- Basicly you develop a feature in a branch until it is ready and not
> 	  impacting other things, then you rebase/cleanup, propose it for
> inclusion and wait for feedback, then merge.
> 	- Stable distributions and vendors get their own branch, they can
> merge, cherry-pick what ever they want.

Agreed on that.

> The issue:
> 	- mtn can not merge. Forcing me to manually delete files in one copy
> to do a merge is not acceptable.

argh on that too

> 	- I lack a GUI to easily browse the repository

Does Mercurial has such one? GIT has gitk, qgit and probably something 
more.

> 	- I can not clean up changes before I push them!

I do not know what exactly you mean here but from what I know it is doable 
with GIT (exporting and re-importing patchsets).

> I want that we use more branches for development, apply review on them,
> land/merge/push these branches after review, pull peoples changes from
> other hosts, work on perfetch patch series before landing patches. 

I like idea.

> I believe we need to deploy this kind of development in OE again and as
> mtn is the obstacle to this kind of development I propose to switch to
> another SCM system that allows us to develop OpenEmbedded the way it
> should be developed.

> My criteria:

> 	- Should have branches, easy merging, easy merging of merges
> 	- Branches and merging should be cheap
> 	- Make it easy to put the OE tree into another SCM and still be able
> 	  to merge (git-svn and such)
> 	- A good graphical tool to browse the repository
> 	- A good and maintained web frontend
> 	- A good set of builtin tools (e.g. like git-add -i and git-rebase -i)

Sounds like GIT :)

> I think the two options are hg and git, I tend to favor git due the
> size of its community. I want to switch OE to one of these systems by
> the end of this month and start using more branches and creating
> perfect patch series again.

When I have to choose between Mercurial (hg) and GIT I prefer to choose 
GIT. It is because this one is more known to me and I know that it has 
large users base. I also knew developers with lot of git experience so it 
is easier to seek for help.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

 Learn the facts and make up your own damn mind. That's why you have one.

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Marcin Juszkiewicz schreef:

| When I have to choose between Mercurial (hg) and GIT I prefer to choose
| GIT. It is because this one is more known to me and I know that it has
| large users base. I also knew developers with lot of git experience so it
| is easier to seek for help.

CVS also has a large user base and lots of OE developers have lots of
experience with it.

See why those are bad arguments? Since Holger wants to switch for
*technical* reasons we shouldn't allow such "OMG GIT IS POPULAR LOL"
arguments. And I bet there will be people saying "OE always to be
special" if we (again) stay clear from git and choose hg.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH1mLxMkyGM64RGpERApj6AKCldx9gsg7jlexKcOhqudSnS7ZYNACgjQ5J
GFEniWLfB5l40L5OKrlbddI=
=pgJy
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Tue, 2008-03-11 at 11:46 +0100, Koen Kooi wrote:
> Marcin Juszkiewicz schreef:
> | When I have to choose between Mercurial (hg) and GIT I prefer to choose
> | GIT. It is because this one is more known to me and I know that it has
> | large users base. I also knew developers with lot of git experience so it
> | is easier to seek for help.
> 
> CVS also has a large user base and lots of OE developers have lots of
> experience with it.
> 
> See why those are bad arguments? Since Holger wants to switch for
> *technical* reasons we shouldn't allow such "OMG GIT IS POPULAR LOL"
> arguments. And I bet there will be people saying "OE always to be
> special" if we (again) stay clear from git and choose hg.

Whilst I agree we should give a lot of weight to technical arguments, a
large active userbase is a good thing for an SCM. It means there are
more howto guides out there, more people who've probably hit your
problem before, more people you can go and ask for advice when something
breaks etc.

There is also an advantage if someone doesn't have to know yet another
SCM to check out OE. I don't have hg installed, I do have git and if we
conducted a poll of other OE devs/users I think we'd see a pattern. So
it is valid to consider it.

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 11:00:01 +0000
Richard Purdie <rpurdie@rpsys.net> wrote:

[]

> Whilst I agree we should give a lot of weight to technical arguments,
> a large active userbase is a good thing for an SCM. It means there are
> more howto guides out there, more people who've probably hit your
> problem before, 

Yeah, I'd say, *every* git user hit your problem before - that
git is inconsistent, poorly implemented set of hacks. And if they grow
to love it, why that can't happen to yourself, right?

> more people you can go and ask for advice when
> something breaks etc.
> 
> There is also an advantage if someone doesn't have to know yet another
> SCM to check out OE. I don't have hg installed, I do have git and if
> we conducted a poll of other OE devs/users I think we'd see a
> pattern. 

I probably dumb, but that pattern would be CVS? SVN? no? Nevermind, of
course.

> So it is valid to consider it.
> 
> Cheers,
> 
> Richard

[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Tue, 2008-03-11 at 14:30 +0200, Paul Sokolovsky wrote:
> Yeah, I'd say, *every* git user hit your problem before - that
> git is inconsistent, poorly implemented set of hacks. And if they grow
> to love it, why that can't happen to yourself, right?

You will never have seen me argue git has a nice UI. I've said quite the
opposite on many occasions. I have said its powerful but thats
different.

> > There is also an advantage if someone doesn't have to know yet another
> > SCM to check out OE. I don't have hg installed, I do have git and if
> > we conducted a poll of other OE devs/users I think we'd see a
> > pattern. 
> 
> I probably dumb, but that pattern would be CVS? SVN? no? Nevermind, of
> course.

I'm assuming we're considering distributed scms but you know this ;-)

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 12:39:13 +0000
Richard Purdie <rpurdie@rpsys.net> wrote:

> On Tue, 2008-03-11 at 14:30 +0200, Paul Sokolovsky wrote:
> > Yeah, I'd say, *every* git user hit your problem before - that
> > git is inconsistent, poorly implemented set of hacks. And if they
> > grow to love it, why that can't happen to yourself, right?
> 
> You will never have seen me argue git has a nice UI. I've said quite
> the opposite on many occasions. I have said its powerful but thats
> different.

It's nice to have that said explicit - different. Supposedly it's more
powerful for developers, but how good it is for end users? How many
industry entities select git as their in-house SCM? I doubt that too
many, knowing too well that many still select just CVS.

> 
> > > There is also an advantage if someone doesn't have to know yet
> > > another SCM to check out OE. I don't have hg installed, I do have
> > > git and if we conducted a poll of other OE devs/users I think
> > > we'd see a pattern. 
> > 
> > I probably dumb, but that pattern would be CVS? SVN? no? Nevermind,
> > of course.
> 
> I'm assuming we're considering distributed scms but you know this ;-)

Yes, I'm trying to hint that arguments like having something already
installed, or some niche, but big project already using it, are not
necessarily valid for the topic of selecting SCM for OE.

I'd really like someone who lead this idea to actually try few
"advanced" usecases with both git and hg. But if that's not going to
happen, at least let's not pretend that git is going to be "better"
than hg or even mtn. It will be just different, possibly, bringing more
issues overall.

> 
> Cheers,
> 
> Richard

[]


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Tue, 2008-03-11 at 15:03 +0200, Paul Sokolovsky wrote:
> On Tue, 11 Mar 2008 12:39:13 +0000 Richard Purdie <rpurdie@rpsys.net> wrote:
> > You will never have seen me argue git has a nice UI. I've said quite
> > the opposite on many occasions. I have said its powerful but thats
> > different.
> 
> It's nice to have that said explicit - different. Supposedly it's more
> powerful for developers, but how good it is for end users? How many
> industry entities select git as their in-house SCM? I doubt that too
> many, knowing too well that many still select just CVS.

OE is there to serve a multitude of people, both developers and end
users. For the end user, hopefully we can document the basics of "git
clone", "git pull" and "git diff" or documentation already exists for
this. 

Also, I think more end users coming fresh to OE will know how to do this
with git in the current climate than with monotone, hg or any other
distributed SCM.

Regarding industrial entities, hopefully we call agree CVS is a pretty
bad SCM and that proves said industrial entities don't know what they're
doing, usually since it often it comes down to politics rather than
technical merit. I know of a few surprising companies using git FWIW
although I know of a few abominations in use too.
 
> > I'm assuming we're considering distributed scms but you know this ;-)
> 
> Yes, I'm trying to hint that arguments like having something already
> installed, or some niche, but big project already using it, are not
> necessarily valid for the topic of selecting SCM for OE.

You're asking about end users and how we should represent them above
then you claim its irrelevant?

I'm not saying this is the only factor to consider but I am arguing that
its a valid factor to consider.

> I'd really like someone who lead this idea to actually try few
> "advanced" usecases with both git and hg. But if that's not going to
> happen, at least let's not pretend that git is going to be "better"
> than hg or even mtn. It will be just different, possibly, bringing more
> issues overall.

Well, we have use cases explained where mtn has failed and we know git
is better. Some of us use git for other projects like kernel work and in
my/their opinion, we *know* it can do some things better.

Personally my hg knowledge is weak. If thats the case for me, it
probably is for a lot of other people and I think its valid to use that
as a factor. I'm not against learning hg if it solves all our problems,
I just don't think it will.

So, firstly, is anyone else willing to propose any other distributed
SCMs or is this just a choice between hg and git? If so, we have three
options:

1. Continue as we are with monotone
2. Switch to git
3. Switch to hg

We've talked about whether 1 is a good idea or not and assuming its not,
what are the pros/cons of 2/3?

git
---

* Most likely to to be installed on a given newcommer's machine
* Most likely to have been used before by a newcommer
* Has lots of documentation
* Has a lot of users
* Powerful web and visualisation tools
* Very actively growing
[I've not listed the other git features since I don't know how they
compare to hg, help?]

hg
--

* Has a nicer commandline?


These are just the issues I can know for near enough certain. Could one
of the hg proponents please put together a list of what makes its great,
and compare its branching/merge handling features with git?

Another thing we should consider is whether something is likely to
improve over time. This is something we hoped would happen with monotone
and whilst it has to an extent, it hasn't as much as we'd have liked.
Personally I think someone will write a nice frontend (porcelain) for
git eventually but we don't have a guarantee of that. The strength of
the communities in question plays a part here.

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

Richard Purdie wrote:
> So, firstly, is anyone else willing to propose any other distributed
> SCMs or is this just a choice between hg and git? If so, we have three
> options:
> 
> 1. Continue as we are with monotone
> 2. Switch to git
> 3. Switch to hg

Basically, RP has cut to the core of the discussion. This is the 
question that must be resolved.

1) mtn creates pain for a small number of important developers and does 
not effectively support some projects workflows. However, these problems 
limit our ability to promote OE effectively. Continuing with mtn is not 
a long term survival strategy for OE. (Yes, I am wearing a PHB hat when 
I say this.)

2) Personally, I need to improve my git skillz so I can work effectively 
with u-boot and the kernel projects. Professionally speaking, I must 
learn git.

3) Koen's picture of the Hg workflow is very helpful. But for me 
personally, my git needs trump my curiosity about Hg. The bottom line is 
that I have only so many hours in a day to learn things, and I would 
prefer to have to learn a SCM that is already in my queue of things to 
learn.

Although I personally have no particular beef with mtn (I have trained 
my fingers to use it for my needs) I would be fine with a switch to git.

As a final note, as long as OE does not switch to cvs, I would learn 
whatever SCM is chosen since the power of OE outweighs SCM annoyance :)

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 13:44:12 +0000
Richard Purdie <rpurdie@rpsys.net> wrote:

> On Tue, 2008-03-11 at 15:03 +0200, Paul Sokolovsky wrote:
> > On Tue, 11 Mar 2008 12:39:13 +0000 Richard Purdie
> > <rpurdie@rpsys.net> wrote:
> > > You will never have seen me argue git has a nice UI. I've said
> > > quite the opposite on many occasions. I have said its powerful
> > > but thats different.
> > 
> > It's nice to have that said explicit - different. Supposedly it's
> > more powerful for developers, but how good it is for end users? How
> > many industry entities select git as their in-house SCM? I doubt
> > that too many, knowing too well that many still select just CVS.
> 
> OE is there to serve a multitude of people, both developers and end
> users. For the end user, hopefully we can document the basics of "git
> clone", "git pull" and "git diff" or documentation already exists for
> this. 

Hopefully "git pull" and "git diff" do not need any documentation. But
the fact that "git checkout file.ext" actually reverts a file is not
obvious at all. 

Or let's have a look at "git commit --all": "Tell the
command to automatically stage files that have been modified and
deleted, but new files you have not told git about are not affected."
So, it's all, but ... not all at all. And git is full of such quirks.

> Also, I think more end users coming fresh to OE will know how to do
> this with git in the current climate than with monotone, hg or any
> other distributed SCM.

Well, there's some core SCM language which is already known to most
users. git abuses it.

> Regarding industrial entities, hopefully we call agree CVS is a pretty
> bad SCM and that proves said industrial entities don't know what
> they're doing, usually since it often it comes down to politics
> rather than technical merit. I know of a few surprising companies
> using git FWIW although I know of a few abominations in use too.
>  
> > > I'm assuming we're considering distributed scms but you know
> > > this ;-)
> > 
> > Yes, I'm trying to hint that arguments like having something already
> > installed, or some niche, but big project already using it, are not
> > necessarily valid for the topic of selecting SCM for OE.
> 
> You're asking about end users and how we should represent them above
> then you claim its irrelevant?

Sorry, installing a package is <your-favorite-pkgmanager> install
<package>.

> 
> I'm not saying this is the only factor to consider but I am arguing
> that its a valid factor to consider.
> 
> > I'd really like someone who lead this idea to actually try few
> > "advanced" usecases with both git and hg. But if that's not going to
> > happen, at least let's not pretend that git is going to be "better"
> > than hg or even mtn. It will be just different, possibly, bringing
> > more issues overall.
> 
> Well, we have use cases explained where mtn has failed and we know git
> is better. Some of us use git for other projects like kernel work and
> in my/their opinion, we *know* it can do some things better.
> 
> Personally my hg knowledge is weak. If thats the case for me, it
> probably is for a lot of other people and I think its valid to use
> that as a factor. I'm not against learning hg if it solves all our
> problems, I just don't think it will.
> 
> So, firstly, is anyone else willing to propose any other distributed
> SCMs or is this just a choice between hg and git? If so, we have three
> options:
> 
> 1. Continue as we are with monotone
> 2. Switch to git
> 3. Switch to hg
> 
> We've talked about whether 1 is a good idea or not and assuming its
> not, what are the pros/cons of 2/3?
> 
> git
> ---
> 
> * Most likely to to be installed on a given newcommer's machine

On a newcomer's machine, nowadays dash is installed instead of the real
shell, not git or something of that kind.

> * Most likely to have been used before by a newcommer
> * Has lots of documentation

Yeah, every user, once hit the fact that git is not usable out of the
box, spends some small time (read: possibly incompletely, or
incorrectly) to figure out how to do trivial things with it, and then
posts that to his blog, for everyone's confusion.

> * Has a lot of users
> * Powerful web and visualisation tools
> * Very actively growing
> [I've not listed the other git features since I don't know how they
> compare to hg, help?]

* Written as the set of hacks targetted at specific development model,
without much design thought. Remember CVS history? "What's now CVS is
used to be a set of shell scripts around RCS which gradually were
rewritten in C." That's what git now is.

* Started by people (and supposedly continued by people with alike
attitudes) who known to be change punks having a bible at
Documentation/stable_api_nonsense.txt giving them indulgence to make
changes for the purpose of changes, with things like "consistency" and
"interface contract" meaning nothing to them. So, git 1.5 is muuuch
better than 1.4? Who know what will be with 1.6?

> 
> hg
> --
> 
> * Has a nicer commandline?

* Designed to be an SCM from the start, not a "stupid content tracker".
* Written consistently in the sane language
* Has consistent interface for extension using plugins
* Thought to be easy and nice to use. Well-known command core, many
other usability features here-and-there (like local integer incrementing
revision numbers (so if you remember that some change has rev 20, you
know how to diff that with 2 revs before without searching for
anything or remembering funky rev ref syntax)).
* Cross-platform (not "soon" or "almost", but by the design)
* "git with a human face"
* Big names: Mozilla, etc.

> These are just the issues I can know for near enough certain. Could
> one of the hg proponents please put together a list of what makes its
> great, and compare its branching/merge handling features with git?

That's unfortunately what I cannot do, or I would have done already.
My usecases for hg are simple:

1. Default SCM for local projects (had replaced SVN)
2. Replacement for incremental archiver which appears to not exist for
unix. For example, I use it to lazily track changes to /etc on my
machines.
3. Rich-man's quilt replacement.

For all these cases starting to use it:

1. hg init # creates single hidden dir at the top
2. hg ci -A # This is real "all". And yes, it known common shortcuts
# like "ci", unlike git
3. hg diff --patch # as usual

A repo can be cloned by a mere dir copy. Changes can be easily
propagated from "master". Branch are something within the same repo.
Dunno if it's "checkout" (classical) or "switching" style (like git, I
personally keep finding this confusing - kernel folks simply don't have
much choice except for such mess with their datasize).


To my knowledge, neither git not hg record merge/cherypick history
intrinsically.


> Another thing we should consider is whether something is likely to
> improve over time. This is something we hoped would happen with
> monotone and whilst it has to an extent, it hasn't as much as we'd
> have liked. Personally I think someone will write a nice frontend
> (porcelain) for git eventually but we don't have a guarantee of that.

Isn't there bunch already? Or do you hint that they still can't get it
right? Another question - is it so important to select system with bad
interface and hope that one sweet day something better will be stuffed
on top (apparently, to make us answer questions about both interfaces),
comparing to selecting system which has it right from the start? As
usual, the question is rhetoric.

> The strength of the communities in question plays a part here.
> 
> Cheers,
> 
> Richard
> 
> 



-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Tue, 2008-03-11 at 17:39 +0200, Paul Sokolovsky wrote:
> On Tue, 11 Mar 2008 13:44:12 +0000
> Richard Purdie <rpurdie@rpsys.net> wrote:
> Hopefully "git pull" and "git diff" do not need any documentation. But
> the fact that "git checkout file.ext" actually reverts a file is not
> obvious at all. 

What did you expect it to do?

> Or let's have a look at "git commit --all": "Tell the
> command to automatically stage files that have been modified and
> deleted, but new files you have not told git about are not affected."
> So, it's all, but ... not all at all. And git is full of such quirks.

No argument from me. It has quirks, you get used to them...

> > git
> > ---
> > 
> > * Most likely to to be installed on a given newcommer's machine
> 
> On a newcomer's machine, nowadays dash is installed instead of the real
> shell, not git or something of that kind.

This amounts to trolling and I'm really getting sick of it. We're not
talking about shells, we're talking about which distributed scm is the
user most likely to have some experience of and which is most likely to
aleady exist on their machine. But you know this.

> > * Most likely to have been used before by a newcommer
> > * Has lots of documentation
> 
> Yeah, every user, once hit the fact that git is not usable out of the
> box, spends some small time (read: possibly incompletely, or
> incorrectly) to figure out how to do trivial things with it, and then
> posts that to his blog, for everyone's confusion.

Agreed there is a ton of confusion out there about git. There is good
documentation too.

> > * Has a lot of users
> > * Powerful web and visualisation tools
> > * Very actively growing
> > [I've not listed the other git features since I don't know how they
> > compare to hg, help?]
> 
> * Written as the set of hacks targetted at specific development model,
> without much design thought. Remember CVS history? "What's now CVS is
> used to be a set of shell scripts around RCS which gradually were
> rewritten in C." That's what git now is.

I can buy that...

> * Started by people (and supposedly continued by people with alike
> attitudes) who known to be change punks having a bible at
> Documentation/stable_api_nonsense.txt giving them indulgence to make
> changes for the purpose of changes, with things like "consistency" and
> "interface contract" meaning nothing to them. So, git 1.5 is muuuch
> better than 1.4? Who know what will be with 1.6?

... but this sounds like a boulder on your shoulder weighing you down.
The linux kernel Documentation/stable_api_nonsense.txt has little to do
with git and our choice of it as an SCM. That document was GregKH
propaganda not Linus. There are parts of the kernel which have absolute
API (syscalls) and there are parts which don't (function names). Its all
documented and well known about.

What matters is whether upstream are likely to break the on disk format
of git in the future or the data interchange formats. I suggest they are
not likely to do so, at least not in incompatible ways.

[hg pros]

> * Designed to be an SCM from the start, not a "stupid content tracker".
> * Written consistently in the sane language
> * Has consistent interface for extension using plugins
> * Thought to be easy and nice to use. Well-known command core, many
> other usability features here-and-there (like local integer incrementing
> revision numbers (so if you remember that some change has rev 20, you
> know how to diff that with 2 revs before without searching for
> anything or remembering funky rev ref syntax)).
> * Cross-platform (not "soon" or "almost", but by the design)
> * "git with a human face"
> * Big names: Mozilla, etc.

ok, thanks for the list. Just for reference a lot of these reasons are
why we went for monotone...

> My usecases for hg are simple:
> 
> 1. Default SCM for local projects (had replaced SVN)
> 2. Replacement for incremental archiver which appears to not exist for
> unix. For example, I use it to lazily track changes to /etc on my
> machines.
> 3. Rich-man's quilt replacement.

Can you elaborate on its usage as a quilt replacement? Is each stacked
patch a commit?

> A repo can be cloned by a mere dir copy. 

So can git.

> Changes can be easily propagated from "master".

So can git.

> Branch are something within the same repo.

Hmm, not sure what you mean here.

> Dunno if it's "checkout" (classical) or "switching" style (like git, I
> personally keep finding this confusing - kernel folks simply don't have
> much choice except for such mess with their datasize).

I'm told its checkout style.

> To my knowledge, neither git not hg record merge/cherypick history
> intrinsically.

Merge history is stored in git, rebase and cherrypick is not. The nature
of a rebase/cherrypick operation precludes history by design really.

> > Another thing we should consider is whether something is likely to
> > improve over time. This is something we hoped would happen with
> > monotone and whilst it has to an extent, it hasn't as much as we'd
> > have liked. Personally I think someone will write a nice frontend
> > (porcelain) for git eventually but we don't have a guarantee of that.
> 
> Isn't there bunch already? Or do you hint that they still can't get it
> right? 

I've not tried them since I didn't know about them although admittedly
I'd not looked. Its nice to know people are addressing the issue.

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 16:15:33 +0000
Richard Purdie <rpurdie@rpsys.net> wrote:

> On Tue, 2008-03-11 at 17:39 +0200, Paul Sokolovsky wrote:
> > On Tue, 11 Mar 2008 13:44:12 +0000
> > Richard Purdie <rpurdie@rpsys.net> wrote:
> > Hopefully "git pull" and "git diff" do not need any documentation.
> > But the fact that "git checkout file.ext" actually reverts a file
> > is not obvious at all. 
> 
> What did you expect it to do?

I expect: 1) checkout to do check out; 2) have an explicit command
withe explicit name to revert changes; 3) nothing else except that
command to trash my changes.

> 
> > Or let's have a look at "git commit --all": "Tell the
> > command to automatically stage files that have been modified and
> > deleted, but new files you have not told git about are not
> > affected." So, it's all, but ... not all at all. And git is full of
> > such quirks.
> 
> No argument from me. It has quirks, you get used to them...

My argument is that once out of this mirror world, you forget these
quirks as useless luggage on your mind, and coming back again, need to
relearn them again. That's worse than being able to use different
systems with the common set of knowledge.

> 
> > > git
> > > ---
> > > 
> > > * Most likely to to be installed on a given newcommer's machine
> > 
> > On a newcomer's machine, nowadays dash is installed instead of the
> > real shell, not git or something of that kind.
> 
> This amounts to trolling and I'm really getting sick of it. We're not
> talking about shells, we're talking about which distributed scm is the
> user most likely to have some experience of and which is most likely
> to aleady exist on their machine. But you know this.

And I'm talking about what to answer to real *newbie* *users* who will
hit funky git issues again and again, just the same as they hit mtn
ones. I did lot of explanation why OE uses mtn already, and would like
to at least be prepared to respond to similar question regarding git
something more convincing than "git!!!!111 As seen on TV!" (read:
on Linux Kernel).

> 
> > > * Most likely to have been used before by a newcommer
> > > * Has lots of documentation
> > 
> > Yeah, every user, once hit the fact that git is not usable out of
> > the box, spends some small time (read: possibly incompletely, or
> > incorrectly) to figure out how to do trivial things with it, and
> > then posts that to his blog, for everyone's confusion.
> 
> Agreed there is a ton of confusion out there about git. There is good
> documentation too.
> 
> > > * Has a lot of users
> > > * Powerful web and visualisation tools
> > > * Very actively growing
> > > [I've not listed the other git features since I don't know how
> > > they compare to hg, help?]
> > 
> > * Written as the set of hacks targetted at specific development
> > model, without much design thought. Remember CVS history? "What's
> > now CVS is used to be a set of shell scripts around RCS which
> > gradually were rewritten in C." That's what git now is.
> 
> I can buy that...
> 
> > * Started by people (and supposedly continued by people with alike
> > attitudes) who known to be change punks having a bible at
> > Documentation/stable_api_nonsense.txt giving them indulgence to make
> > changes for the purpose of changes, with things like "consistency"
> > and "interface contract" meaning nothing to them. So, git 1.5 is
> > muuuch better than 1.4? Who know what will be with 1.6?
> 
> ... but this sounds like a boulder on your shoulder weighing you down.
> The linux kernel Documentation/stable_api_nonsense.txt has little to
> do with git and our choice of it as an SCM. That document was GregKH
> propaganda not Linus. There are parts of the kernel which have
> absolute API (syscalls) and there are parts which don't (function
> names). Its all documented and well known about.
> 
> What matters is whether upstream are likely to break the on disk
> format of git in the future or the data interchange formats. I
> suggest they are not likely to do so, at least not in incompatible
> ways.
> 
> [hg pros]
> 
> > * Designed to be an SCM from the start, not a "stupid content
> > tracker".
> > * Written consistently in the sane language
> > * Has consistent interface for extension using plugins
> > * Thought to be easy and nice to use. Well-known command core, many
> > other usability features here-and-there (like local integer
> > incrementing revision numbers (so if you remember that some change
> > has rev 20, you know how to diff that with 2 revs before without
> > searching for anything or remembering funky rev ref syntax)).
> > * Cross-platform (not "soon" or "almost", but by the design)
> > * "git with a human face"
> > * Big names: Mozilla, etc.
> 
> ok, thanks for the list. Just for reference a lot of these reasons are
> why we went for monotone...
> 
> > My usecases for hg are simple:
> > 
> > 1. Default SCM for local projects (had replaced SVN)
> > 2. Replacement for incremental archiver which appears to not exist
> > for unix. For example, I use it to lazily track changes to /etc on
> > my machines.
> > 3. Rich-man's quilt replacement.
> 
> Can you elaborate on its usage as a quilt replacement? Is each stacked
> patch a commit?

Heh, I know you'll catch on this. Nope, by "quilt replacement" I mean
that nowadays, when I want to make a patch, I use not diff, not quilt,
but hg. It doesn't have push/pop ability builtin (nor even rebasing
AFAIK) - such stuff is handled by plugins. And there's plugin for
stacked stuff, but I personally didn't have need to play with it so far.

> 
> > A repo can be cloned by a mere dir copy. 
> 
> So can git.

Nope, not "so can git". "So can hg"! My personal idea of hg's idea is
that they want to have the same functionality as git, but in more
nice, sane manner. That's the impression I got. But I don't have proofs
based on my real experience regarding more advanced usage than "just
SCM", which place it did win for myself however.

> 
> > Changes can be easily propagated from "master".
> 
> So can git.
> 
> > Branch are something within the same repo.
> 
> Hmm, not sure what you mean here.

It's common misconception that hg doesn't have branches - they do, but
fairly enough suggest to not bother with them unless needed, and instead
just clone repos, as that's the easiest way to "branch".

> 
> > Dunno if it's "checkout" (classical) or "switching" style (like
> > git, I personally keep finding this confusing - kernel folks simply
> > don't have much choice except for such mess with their datasize).
> 
> I'm told its checkout style.
> 
> > To my knowledge, neither git not hg record merge/cherypick history
> > intrinsically.
> 
> Merge history is stored in git, rebase and cherrypick is not. The
> nature of a rebase/cherrypick operation precludes history by design
> really.

Well, cherrypick takes revision, so can record that fact somehow. The
matter that one may need to edit work copy to fix conflicts during
cherry-picking shouldn't be excuse for noone trying to do that... Just
thoughts on SCM feature set...

> 
> > > Another thing we should consider is whether something is likely to
> > > improve over time. This is something we hoped would happen with
> > > monotone and whilst it has to an extent, it hasn't as much as we'd
> > > have liked. Personally I think someone will write a nice frontend
> > > (porcelain) for git eventually but we don't have a guarantee of
> > > that.
> > 
> > Isn't there bunch already? Or do you hint that they still can't get
> > it right? 
> 
> I've not tried them since I didn't know about them although admittedly
> I'd not looked. Its nice to know people are addressing the issue.

Cogito is obvious candidate for user-friendliness and better
consistency. I even used it once, because I just *couldn't* find out
how to do something with bare git (don't remember what it was now, but
it involved doing something about specific rev). There's stacked git for
something quilty, etc. But again, in my list, that's complication with
supporting users trying to use all that blossom, instead of using
something single and consistent... (talking users, as developer can do
lots of things anyway with almost anything, modulo laziness and
superstitions).

> 
> Cheers,
> 
> Richard
> 



-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Tim Bird]

Richard Purdie wrote:
> On Tue, 2008-03-11 at 15:03 +0200, Paul Sokolovsky wrote:
>> It's nice to have that said explicit - different. Supposedly it's more
>> powerful for developers, but how good it is for end users? How many
>> industry entities select git as their in-house SCM? I doubt that too
>> many, knowing too well that many still select just CVS.



> Regarding industrial entities, hopefully we call agree CVS is a pretty
> bad SCM and that proves said industrial entities don't know what they're
> doing, usually since it often it comes down to politics rather than
> technical merit. I know of a few surprising companies using git FWIW
> although I know of a few abominations in use too.

Just a data point...
Sony uses git as its in-house SCM for Linux-related work.
We also use quilt.

 > Also, I think more end users coming fresh to OE will know how to do this
 > with git in the current climate than with monotone, hg or any other
 > distributed SCM.

I would agree with this.  monotone is a big reason I'm still
an observer of OE rather than an active participant.
As such, I shouldn't really have a vote.  But if I did it would
be for git, purely for personal economy of training.

  -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: Reconsidering the work flow and how the SCM system fits in

[Rodrigo Vivi]

I'd like to tell you that we (Mamona) has just migrate to git
repository. We are pulling the OE's changes from Holger's git tree
since last week.

We've decided to migrate because we were having lots of problems with
monotone propagate. We had problems that neither monotone developers
could help us to figure them out. It was so annoying. Most of our
problems was related to "Non content conflicts".

At last OEDEM we talked a lot about Monotone x Git but I couldn't
contribute because I had never used git before. I remember Koen
complaining about git documentation and all.

Nowdays I'm using git to work on linux-omap, Xorg and Mamona and I can
tell that git is so much better. It is easier, faster and simplest.

What about documentation? Amazing. The man pages are complete and
there are many big projects already using git whose has lots of
documentations about how to deal with unexpected issues (edit old
commits, conflicts, etc)

So we believe that migrate to git is the best option.

Cheers

On Tue, Mar 11, 2008 at 1:12 PM, Tim Bird <tim.bird@am.sony.com> wrote:
> Richard Purdie wrote:
>  > On Tue, 2008-03-11 at 15:03 +0200, Paul Sokolovsky wrote:
>
> >> It's nice to have that said explicit - different. Supposedly it's more
>  >> powerful for developers, but how good it is for end users? How many
>  >> industry entities select git as their in-house SCM? I doubt that too
>  >> many, knowing too well that many still select just CVS.
>
>
>
>
> > Regarding industrial entities, hopefully we call agree CVS is a pretty
>  > bad SCM and that proves said industrial entities don't know what they're
>  > doing, usually since it often it comes down to politics rather than
>  > technical merit. I know of a few surprising companies using git FWIW
>  > although I know of a few abominations in use too.
>
>  Just a data point...
>  Sony uses git as its in-house SCM for Linux-related work.
>  We also use quilt.
>
>
>   > Also, I think more end users coming fresh to OE will know how to do this
>   > with git in the current climate than with monotone, hg or any other
>   > distributed SCM.
>
>  I would agree with this.  monotone is a big reason I'm still
>  an observer of OE rather than an active participant.
>  As such, I shouldn't really have a vote.  But if I did it would
>  be for git, purely for personal economy of training.
>
>   -- Tim
>
>  =============================
>  Tim Bird
>  Architecture Group Chair, CE Linux Forum
>  Senior Staff Engineer, Sony Corporation of America
>  =============================
>
>
>
>
>  _______________________________________________
>  Openembedded-devel mailing list
>  Openembedded-devel@lists.openembedded.org
>  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Rodrigo Vivi
INdT - Instituto Nokia de Tecnologia
Blog: http://blog.vivi.eng.br
GPG: 0x905BE242 @ wwwkeys.pgp.net

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 09:12:21 -0700
Tim Bird <tim.bird@am.sony.com> wrote:

> Richard Purdie wrote:
> > On Tue, 2008-03-11 at 15:03 +0200, Paul Sokolovsky wrote:
> >> It's nice to have that said explicit - different. Supposedly it's
> >> more powerful for developers, but how good it is for end users?
> >> How many industry entities select git as their in-house SCM? I
> >> doubt that too many, knowing too well that many still select just
> >> CVS.
> 
> 
> 
> > Regarding industrial entities, hopefully we call agree CVS is a
> > pretty bad SCM and that proves said industrial entities don't know
> > what they're doing, usually since it often it comes down to
> > politics rather than technical merit. I know of a few surprising
> > companies using git FWIW although I know of a few abominations in
> > use too.
> 
> Just a data point...
> Sony uses git as its in-house SCM for Linux-related work.

Well, that's no wonder. Linux uses git, so everyone who does Linux
development uses git. But now people think that: 1) if Linux kernel
uses it, that everyone else must use it; 2) just as for many years
before people have been thinking that there's no other SCM except CVS
which can do better, then now they think there's no other DSCM except
GIT which can do better. 

The last similarity is very striking, and let's just hope that we won't
have reasons to say something like "hopefully we can agree CVS is a
pretty bad SCM and that proves said entities don't know what
they're doing" in regard to GIT.


[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Wed, 2008-03-12 at 01:40 +0200, Paul Sokolovsky wrote:
> On Tue, 11 Mar 2008 09:12:21 -0700 Tim Bird <tim.bird@am.sony.com> wrote:
> > Just a data point...
> > Sony uses git as its in-house SCM for Linux-related work.
> 
> Well, that's no wonder. Linux uses git, so everyone who does Linux
> development uses git. But now people think that: 1) if Linux kernel
> uses it, that everyone else must use it; 2) just as for many years
> before people have been thinking that there's no other SCM except CVS
> which can do better, then now they think there's no other DSCM except
> GIT which can do better. 
> 
> The last similarity is very striking, and let's just hope that we won't
> have reasons to say something like "hopefully we can agree CVS is a
> pretty bad SCM and that proves said entities don't know what
> they're doing" in regard to GIT.

In 10 years time we probably will have a better alternative. Thats fine,
my computer is a bit different to the one I had 10 years ago too.

Here and now, CVS is bad, git has a lot of positives.

How about we goes back to the discussion at hand? Technical merits of
git vs. hg or votes for not switching.

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Florian Boor]

Hi,

Paul Sokolovsky schrieb:
> Yeah, I'd say, *every* git user hit your problem before - that
> git is inconsistent, poorly implemented set of hacks. And if they grow
> to love it, why that can't happen to yourself, right?

in this discussion I really miss information and arguments *for* a particular
solution.
I found some input for the decision here:
http://www.selenic.com/pipermail/mercurial/2005-May/000334.html
(quite old, but easy to read)
http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html
http://www.jukie.net/~bart/blog/git-vs-hg

... and some more.

From what I have read so far it looks like we would have a good solution with
both git and hg. The features seem to be more or less the same. The key
advantage of git is that it is more familiar to many developers. The key
advantage of hg would be a much cleaner and well designed user interface which
is more attractive for people who need to get used to it.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Reconsidering the work flow and how the SCM system fits in

[Petr Stetiar]

Koen Kooi <koen@dominion.kabel.utwente.nl> [2008-03-11 11:46:09]:

> CVS also has a large user base and lots of OE developers have lots of
> experience with it.

Didn't knew, that CVS is "distributed" SCM :-)

My reason for using Git, is, that I could drop my local overlays maintained in
SVN, and could easily use Git's branches for it. It's then really easy to try
out and build different braches and also easier to send patches back to OE.

-- ynezz

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 12:49:38 +0100
Petr Stetiar <ynezz@true.cz> wrote:

> Koen Kooi <koen@dominion.kabel.utwente.nl> [2008-03-11 11:46:09]:
> 
> > CVS also has a large user base and lots of OE developers have lots
> > of experience with it.
> 
> Didn't knew, that CVS is "distributed" SCM :-)
> 
> My reason for using Git, is, that I could drop my local overlays
> maintained in SVN, and could easily use Git's branches for it. It's
> then really easy to try out and build different braches and also
> easier to send patches back to OE.

That's because you don't know hg. Scientific studies has proven it to
be 27.92% easier.

> 
> -- ynezz

[]


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Florian Boor]

Hi,

Paul Sokolovsky schrieb:
> 
> That's because you don't know hg. Scientific studies has proven it to
> be 27.92% easier.

I'm tempted to agree blindly ;) Where did you find this?
*If* the user interaction of hg is much better than git then this would be a
reason to prefer hg.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Florian Boor schreef:
| Hi,
|
| Paul Sokolovsky schrieb:
|> That's because you don't know hg. Scientific studies has proven it to
|> be 27.92% easier.
|
| I'm tempted to agree blindly ;) Where did you find this?
| *If* the user interaction of hg is much better than git then this
would be a
| reason to prefer hg.

When I tested hg during the previous scm round it was way easier to use
than git, most likely because it's modeled after mtn, without the
annoying bugs like non-content conflicts and slowness.

Have a look at
http://www.ivy.fr/mercurial/ref/v1.0/Mercurial-QuickStart-v1.0-120dpi.png

btw, sun picked hg for their opensolaris stuff.

regards,

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

iD8DBQFH1ouDMkyGM64RGpERAjstAJ99n8IfV0DX2zpVcri9nZbDGH3PQwCgrpCI
ZR7nyf2/jXJtOUfo05Ltk8Q=
=wUS/
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 14:24:05 +0100
Florian Boor <florian.boor@kernelconcepts.de> wrote:

> Hi,
> 
> Paul Sokolovsky schrieb:
> > 
> > That's because you don't know hg. Scientific studies has proven it
> > to be 27.92% easier.
> 
> I'm tempted to agree blindly ;) Where did you find this?

Ummm, I seem to lost the links! But I swear I heard that on TV! Also,
grandma in the nearby shop tells the same! ;-)

> *If* the user interaction of hg is much better than git then this
> would be a reason to prefer hg.

I assess that by: can I move away from using a tool for some time, then
come back and continue it using without learning it again. There're some
core commands which work almost the same in cvs/svn/mtn/hg. Git is
the most diverging from them. 

So, I used when played with Familiar's fork repo, and a bit with
kernel, but what I remember about it is that it has some weird
pre-commit buffer (they call it "index"), have many quirky switches,
you may spent time figuring out how to revert local changes, and at the
same time, lose your local changes without you wanting that, etc., etc.


> 
> Greetings
> 
> Florian

[]


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Cliff Brake]

On Tue, Mar 11, 2008 at 7:49 AM, Petr Stetiar <ynezz@true.cz> wrote:

>  My reason for using Git, is, that I could drop my local overlays maintained in
>  SVN, and could easily use Git's branches for it. It's then really easy to try
>  out and build different braches and also easier to send patches back to OE.

I'm really pleased with how easy it is to maintain multiple branches
and quickly switch between branches in one working directory using git
when doing kernel work.  I'm not sure how hg compares as I've not used
it yet.  This is important to me because I work on OE in small,
discontinuous chunks of time, so if I can work on a features in
several branches, and then be able to clean up the changset history
(git rebase -i) before pushing to the public repo, that would be a big
plus for me.  Also being able to easily maintain customer branches in
source control instead of OE overlays would be a big plus.  That said,
I have not tried very hard to do all this in monotone.

Thanks,
Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com

Re: Reconsidering the work flow and how the SCM system fits in

[Petr Stetiar]

Cliff Brake <cliff.brake@gmail.com> [2008-03-11 10:12:52]:

> On Tue, Mar 11, 2008 at 7:49 AM, Petr Stetiar <ynezz@true.cz> wrote:
> 
> >  My reason for using Git, is, that I could drop my local overlays
> >  maintained in SVN, and could easily use Git's branches for it. It's then
> >  really easy to try out and build different braches and also easier to
> >  send patches back to OE.
> 
> I'm really pleased with how easy it is to maintain multiple branches and
> quickly switch between branches in one working directory using git when
> doing kernel work.  I'm not sure how hg compares as I've not used it yet.
> This is important to me because I work on OE in small,

As I've understood it, Hg don't use simple branches inside local repository,
but you've to branch it in another directory outside your repository.  Since
it's using hardlinks it won't waste too much disk space, but it's not as cheap
and easy as in Git probably.

-- ynezz

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Tue, 2008-03-11 at 15:57 +0100, Petr Stetiar wrote:
> Cliff Brake <cliff.brake@gmail.com> [2008-03-11 10:12:52]:
> 
> > On Tue, Mar 11, 2008 at 7:49 AM, Petr Stetiar <ynezz@true.cz> wrote:
> > 
> > >  My reason for using Git, is, that I could drop my local overlays
> > >  maintained in SVN, and could easily use Git's branches for it. It's then
> > >  really easy to try out and build different braches and also easier to
> > >  send patches back to OE.
> > 
> > I'm really pleased with how easy it is to maintain multiple branches and
> > quickly switch between branches in one working directory using git when
> > doing kernel work.  I'm not sure how hg compares as I've not used it yet.
> > This is important to me because I work on OE in small,
> 
> As I've understood it, Hg don't use simple branches inside local repository,
> but you've to branch it in another directory outside your repository.  Since
> it's using hardlinks it won't waste too much disk space, but it's not as cheap
> and easy as in Git probably.

I asked around about hg and this did come up, you don't get cheap
branching like you do with git, you have to use a separate
directory/checkout per branch.

For anyone who's used git, cheap branching is a wonderful thing[1]. This
is enough to swing things for me since its one feature of git I'd love
to be able to use with OE.

[1] unless you're dwmw2[2]
[2] don't go there ;-)

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 15:49:48 +0000
Richard Purdie <rpurdie@rpsys.net> wrote:

> 
> On Tue, 2008-03-11 at 15:57 +0100, Petr Stetiar wrote:
> > Cliff Brake <cliff.brake@gmail.com> [2008-03-11 10:12:52]:
> > 
> > > On Tue, Mar 11, 2008 at 7:49 AM, Petr Stetiar <ynezz@true.cz>
> > > wrote:
> > > 
> > > >  My reason for using Git, is, that I could drop my local
> > > > overlays maintained in SVN, and could easily use Git's branches
> > > > for it. It's then really easy to try out and build different
> > > > braches and also easier to send patches back to OE.
> > > 
> > > I'm really pleased with how easy it is to maintain multiple
> > > branches and quickly switch between branches in one working
> > > directory using git when doing kernel work.  I'm not sure how hg
> > > compares as I've not used it yet. This is important to me because
> > > I work on OE in small,
> > 
> > As I've understood it, Hg don't use simple branches inside local
> > repository, but you've to branch it in another directory outside
> > your repository.  Since it's using hardlinks it won't waste too
> > much disk space, but it's not as cheap and easy as in Git probably.
> 
> I asked around about hg and this did come up, you don't get cheap
> branching like you do with git, you have to use a separate
> directory/checkout per branch.
> 
> For anyone who's used git, cheap branching is a wonderful thing[1].

I personally don't see anything wonderful in that, and glad that some
orthodoxes share this point of view. Kernel people have it because they
are poor, poor people who created hundreds of megabytes of entities and
don't have big enough hdds to deal with them comfortably (and if they
have, their users don't), so they must play such weird tricks as the
need to evaporate current branch to work on another.

I can call svn as witness - it supports both models. But I yet need to
see someone who in sober mind and given a choice, would use "svn
switch" back and forth instead of checking out needed branches to have
them side by side.

> This is enough to swing things for me since its one feature of git
> I'd love to be able to use with OE.
> 
> [1] unless you're dwmw2[2]
> [2] don't go there ;-)
> 
> Cheers,
> 
> Richard

[]


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Wed, 2008-03-12 at 01:49 +0200, Paul Sokolovsky wrote:
> On Tue, 11 Mar 2008 15:49:48 +0000
> Richard Purdie <rpurdie@rpsys.net> wrote:
> > I asked around about hg and this did come up, you don't get cheap
> > branching like you do with git, you have to use a separate
> > directory/checkout per branch.
> > 
> > For anyone who's used git, cheap branching is a wonderful thing[1].
> 
> I personally don't see anything wonderful in that, and glad that some
> orthodoxes share this point of view. Kernel people have it because they
> are poor, poor people who created hundreds of megabytes of entities and
> don't have big enough hdds to deal with them comfortably (and if they
> have, their users don't), so they must play such weird tricks as the
> need to evaporate current branch to work on another.
>
> I can call svn as witness - it supports both models. But I yet need to
> see someone who in sober mind and given a choice, would use "svn
> switch" back and forth instead of checking out needed branches to have
> them side by side.

svn switch is in no way similar to the way git's cheap branching works.

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Wed, 12 Mar 2008 00:09:58 +0000
Richard Purdie <rpurdie@rpsys.net> wrote:

> On Wed, 2008-03-12 at 01:49 +0200, Paul Sokolovsky wrote:
> > On Tue, 11 Mar 2008 15:49:48 +0000
> > Richard Purdie <rpurdie@rpsys.net> wrote:
> > > I asked around about hg and this did come up, you don't get cheap
> > > branching like you do with git, you have to use a separate
> > > directory/checkout per branch.
> > > 
> > > For anyone who's used git, cheap branching is a wonderful
> > > thing[1].
> > 
> > I personally don't see anything wonderful in that, and glad that
> > some orthodoxes share this point of view. Kernel people have it
> > because they are poor, poor people who created hundreds of
> > megabytes of entities and don't have big enough hdds to deal with
> > them comfortably (and if they have, their users don't), so they
> > must play such weird tricks as the need to evaporate current branch
> > to work on another.
> >
> > I can call svn as witness - it supports both models. But I yet need
> > to see someone who in sober mind and given a choice, would use "svn
> > switch" back and forth instead of checking out needed branches to
> > have them side by side.
> 
> svn switch is in no way similar to the way git's cheap branching
> works.

Doesn't it? That must be only due to my naivete regarding git's cheap
branching. Because otherwise they would seem oh so similar to me - svn
revisions are lightweight, any of them can be a tag, a branch, and you
can do arbitrary travels in time and space with svn, all using one
consistent interface.

Well, eager to fix aforementioned naivete, I proceeded to google, and
the first hit on the matter I got was good blog-talk we just recently
discussed: http://blog.madism.org/index.php/2008/02/19/150-git-branches

"but because they are a cheap operation, not in the SVN sense at all,
but because a branch in git is a name, and 40 hexadecimal bytes". Yeah,
that must be it! The reason why svn branches are in no way similar to
git's!

I did stop with this hit, preferring to stay with my naivete - it's
just more comfortable to think of git as just yet another SCM with
its own set of known issues, than as the center of the world, a magic
tool to solve all development needs. Just my 2 cent opinion.


> 
> Cheers,
> 
> Richard
> 
> 
> 



-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Leon Woestenberg]

Hello all,

having very little experience with both git and hg, I needed to look
for other people's thoughts on this.
I found this e-mail from Carl Worth extremely insightfull in the
decision for either hg or git:

http://lists.freedesktop.org/archives/cairo/2006-February/006255.html

His arguments on the (main two) differences strongly favors me to move
to GIT, not HG.


Regards,
-- 
Leon 'likewise'

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Leon Woestenberg schreef:
| Hello all,
|
| having very little experience with both git and hg, I needed to look
| for other people's thoughts on this.
| I found this e-mail from Carl Worth extremely insightfull in the
| decision for either hg or git:
|
| http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
|
| His arguments on the (main two) differences strongly favors me to move
| to GIT, not HG.

Actually it shows that hg fits better into the OE way of using a DSCM:
central repo (and mirrors) with distributed developers.

I keep hearing people saying that they have no clue on how to setup a
git-server for OE where we can commit things as usual, while with hg
it's just 'hg serve'.



regards,

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

iD8DBQFH2Cg6MkyGM64RGpERArCvAJ0ZOXNRysB3/I5HNJwuhto25TrXAQCffaad
VD7lvC0aO123KP3MOPDtweU=
=aHj0
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

Koen Kooi wrote:

> I keep hearing people saying that they have no clue on how to setup a
> git-server for OE where we can commit things as usual, while with hg
> it's just 'hg serve'.

I think some people have a clue, but it is not as easy as 'hg serve' :)

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Reconsidering the work flow and how the SCM system fits in

[Rodrigo Vivi]

>  I keep hearing people saying that they have no clue on how to setup a
>  git-server for OE where we can commit things as usual, while with hg
>  it's just 'hg serve'.

We have a Mamona git repository that we call by server where we can
push, pull, etc...
Aloisio has created it using a bear option that is a repository
without a workdir.

So I didn't get what you want... A database?

>  regards,
>
>  Koen
>
> -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.5 (Darwin)
>
>  iD8DBQFH2Cg6MkyGM64RGpERArCvAJ0ZOXNRysB3/I5HNJwuhto25TrXAQCffaad
>  VD7lvC0aO123KP3MOPDtweU=
>  =aHj0
>  -----END PGP SIGNATURE-----
>
>
>
>
>  _______________________________________________
>  Openembedded-devel mailing list
>  Openembedded-devel@lists.openembedded.org
>  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Rodrigo Vivi
INdT - Instituto Nokia de Tecnologia
Blog: http://blog.vivi.eng.br
GPG: 0x905BE242 @ wwwkeys.pgp.net

Re: Reconsidering the work flow and how the SCM system fits in

[Leon Woestenberg]

Hello Koen, all,

On Wed, Mar 12, 2008 at 8:00 PM, Koen Kooi
<koen@dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  | http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
>  |
>  | His arguments on the (main two) differences strongly favors me to move
>  | to GIT, not HG.
>
>  Actually it shows that hg fits better into the OE way of using a DSCM:
>  central repo (and mirrors) with distributed developers.
>
Quoting Carl: "Namely, it [hg] appears to force a more centralized,
(or at least, a more strictly hierarchical), model on the development
process, while git allows a more fully distributed model making it
easier for users to pull (even speculatively with "fetch") from
multiple sources, track them in the local repository as separate
branches and merge when appropriate."

Carl carefully uses the words "force" and "allows". Git does not
preclude a central model, whilst still allowing more centralized
development.

And the centralized way we work currently is also DUE to us using mtn,
i.e. it forces us more or less to work this way.
Is that the desired way? Yes, for us it might be. For 3rd party
vendors it might not be. They might want to run their own GIT repo,
but keep pulling from OE (or vice versa).

My view at the desired model:
- central repository with mirrors
- lightweight branches for the active developers so that intrusive
changes can be worked on in parallel, but shared fashion.
- easy push/pull/cherrypick from cloned repositories branches, given
that we might see more and more vendors stepping into the OE
bandwagon.

Some thoughts:
- Why wouldn't the kernel model work for us? There is one upstream
tree and distributed developers.
- Suppose we were using GIT today, would we consider going to HG or MTN?
- Suppose we were using HG today, would we consider going to GIT or MTN?

Proposal: Can we work with MTN and GIT, or MTN and HG in parallel?
I.e. each developer has to do everything DOUBLE, has two checkouts
against two SCM systems, and then learn in practise what works best?
:-)


Regards,
-- 
Leon

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Leon Woestenberg schreef:
| Hello Koen, all,
|
| On Wed, Mar 12, 2008 at 8:00 PM, Koen Kooi
| <koen@dominion.kabel.utwente.nl> wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|>  | http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
|>  |
|>  | His arguments on the (main two) differences strongly favors me to move
|>  | to GIT, not HG.
|>
|>  Actually it shows that hg fits better into the OE way of using a DSCM:
|>  central repo (and mirrors) with distributed developers.
|>
| Quoting Carl: "Namely, it [hg] appears to force a more centralized,
| (or at least, a more strictly hierarchical), model on the development
| process, while git allows a more fully distributed model making it
| easier for users to pull (even speculatively with "fetch") from
| multiple sources, track them in the local repository as separate
| branches and merge when appropriate."
|
| Carl carefully uses the words "force" and "allows". Git does not
| preclude a central model, whilst still allowing more centralized
| development.
|
| And the centralized way we work currently is also DUE to us using mtn,
| i.e. it forces us more or less to work this way.

That isn't true, after the bitkeeper switch we *decided* to to it this
way, instead of going fully distributed.


| Some thoughts:
| - Why wouldn't the kernel model work for us? There is one upstream
| tree and distributed developers.
| - Suppose we were using GIT today, would we consider going to HG or MTN?

Yes, since we would all remember git 1.4 throwing away all our local
changes, the lack of docs and the horrible, horrible ui.

| - Suppose we were using HG today, would we consider going to GIT or MTN?

I don't think we would since we would go for horrible UI or slowness.

| Proposal: Can we work with MTN and GIT, or MTN and HG in parallel?

We did that before and did go for hg because of a bug in 'hg serve',
which has been solved nowadays.
And if we go for hg there is no learning curve, since the hg ui was
based on the monotone one.


regards,

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

iD8DBQFH2EDeMkyGM64RGpERAm3MAKCBouBagUxRyN9NXK4Ww5PB1dFu0ACbB9ge
TpsBfnHFA8/D6YVp4Eu3WtI=
=XwPg
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Stelios Koroneos]

> 
> Proposal: Can we work with MTN and GIT, or MTN and HG in parallel?
> I.e. each developer has to do everything DOUBLE, has two 
> checkouts against two SCM systems, and then learn in practise 
> what works best?
> :-)

The reasons we should not do something like that are better described here
:)
http://en.wikipedia.org/wiki/Sadism_and_masochism

Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com
 

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Wed, 12 Mar 2008 21:26:30 +0100
"Leon Woestenberg" <leon.woestenberg@gmail.com> wrote:

> Hello Koen, all,
> 
> On Wed, Mar 12, 2008 at 8:00 PM, Koen Kooi
> <koen@dominion.kabel.utwente.nl> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> >  |
> > http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
> > | | His arguments on the (main two) differences strongly favors me
> > to move | to GIT, not HG.
> >
> >  Actually it shows that hg fits better into the OE way of using a
> > DSCM: central repo (and mirrors) with distributed developers.
> >
> Quoting Carl: "Namely, it [hg] appears to force a more centralized,
> (or at least, a more strictly hierarchical), model on the development
> process, while git allows a more fully distributed model making it
> easier for users to pull (even speculatively with "fetch") from
> multiple sources, track them in the local repository as separate
> branches and merge when appropriate."
> 
> Carl carefully uses the words "force" and "allows". Git does not
> preclude a central model, whilst still allowing more centralized
> development.

Well, in practice it happens not exactly that way. In practice, git
proponents happen to overestimate universal usefulness of some of git
features, and underestimate problems those feature may bring in some
cases, and yet use those features to push git's superiority.

I find one of the links among those posted by Cliff Blake very good
display of that:
http://www-cs-students.stanford.edu/~blynn/gitmagic/ch04.html . That's
generally good read, I personally love lively and literary style, but
well, gentleman's idea why git is cool appears to be based on following
facts: 1) git was the first system SCM system he used (at all appears
- we apparently have new generation of developers growing, who don't
know what CVS is. LOL, or sigh.); 2) his Internet connection sucks.

> And the centralized way we work currently is also DUE to us using mtn,
> i.e. it forces us more or less to work this way.

No, centralized way is due to way humans form communities. Linux kernel
is also works that way. Only Linus' repo is Linux kernel, anything else
is just somebody's hacks on that.

> Is that the desired way? Yes, for us it might be. For 3rd party
> vendors it might not be. They might want to run their own GIT repo,
> but keep pulling from OE (or vice versa).

That can be done with any DSCM, and could be done with mtn.

> My view at the desired model:
> - central repository with mirrors
> - lightweight branches for the active developers so that intrusive
> changes can be worked on in parallel, but shared fashion.
> - easy push/pull/cherrypick from cloned repositories branches, given
> that we might see more and more vendors stepping into the OE
> bandwagon.
> 
> Some thoughts:
> - Why wouldn't the kernel model work for us? There is one upstream
> tree and distributed developers.

Isn't that how we work already? Don't let me guess, but give myself as
example - I'm working on some things over long period of time, then
long period of time may pass before they are pushed to central repo.
Isn't that what you mean by "distributed"? Or if there're no
"lightweight branch" stamp, it's not distributed.

> - Suppose we were using GIT today, would we consider going to HG or
> MTN?

Who knows?

> - Suppose we were using HG today, would we consider going to GIT or
> MTN?

Who knows?


Getting answers for questions like above are exactly why I participate
in this discussion. I missed previous switchover, but I'm trying to
grasp what exactly happens now and why? What has happened recently
which wasn't the case a year ago? Why we get big amounts of strange
confessions that people don't participate well enough in OE and hate it
because of it - now, if it was so for couple of years? Newcomers
suffered mtn *all* the time, I myself coming in 1.5 years had lots of
gore with it, thought gradually it *improved*, not become worse.

Unfortunately, the only reasonable answer I have for myself is that
coredevs finally ate some of Monotone fun. So, users' complaints were
of no avail, but feeling it on own skin is better. So, they hasted to
move somewhere. But where? I have strong suspicion that where it's more
easier and comfortable to them, users' needs and troubles might be
ignored again.

Well, we have by now we broke preconception that git is the *only*
choice to migrate too, and possible situation that hg was mentioned in
the initial mail for sole purpose of emulating pluralism. So, even if
git will be chosen (which is quite likely), then at least we can be sure
that wasn't done blindly, without understanding what that choice would
mean.

> 
> Proposal: Can we work with MTN and GIT, or MTN and HG in parallel?
> I.e. each developer has to do everything DOUBLE, has two checkouts
> against two SCM systems, and then learn in practise what works best?
> :-)


Hopefully not. But one of the outcome of this discussion may be  that
core devs ask the original proposer to evaluate both choices in more
detail before hasting with the switch. (Note that I personally don't
seek such result or want to complicate proposer's task. But I would
really like to know what to answer people who will hit this or that
tool issues, and I do come at such situations regularly - far more
frequent than I'd like, so knowing that needs and troubles of "mere"
users were ignored during selection, doesn't help me at all with
doing community support.)

> 
> 
> Regards,
> -- 
> Leon


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Wed, 2008-03-12 at 21:26 +0100, Leon Woestenberg wrote:
> On Wed, Mar 12, 2008 at 8:00 PM, Koen Kooi
> <koen@dominion.kabel.utwente.nl> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> >  | http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
> >  |
> >  | His arguments on the (main two) differences strongly favors me to move
> >  | to GIT, not HG.
> >
> >  Actually it shows that hg fits better into the OE way of using a DSCM:
> >  central repo (and mirrors) with distributed developers.
> >
> Quoting Carl: "Namely, it [hg] appears to force a more centralized,
> (or at least, a more strictly hierarchical), model on the development
> process, while git allows a more fully distributed model making it
> easier for users to pull (even speculatively with "fetch") from
> multiple sources, track them in the local repository as separate
> branches and merge when appropriate."
> 
> Carl carefully uses the words "force" and "allows". Git does not
> preclude a central model, whilst still allowing more centralized
> development.

Thanks for posting the link, I've found it very interesting and to me it
shows that I'm not going to like hg :/.

Why? The *big* *big* win with git is the way it deals with branches. I
really can't stress how useful they are and how much they improve the
way you can use the SCM. Good branch support is the major reason I'd
like to see OE switch SCM in the first place.

Whilst I think OE will always have a central master .dev repository I
see a lot of gain from having branches. I would have happily put the
sysroot changes into a branch and likewise the packaged-staging stuff
I'm working on. As it is I'm keeping it locally uncommitted with no
version tracking since I don't really want to play games with monotone.
I've also got the problem that I've found some bugs in bitbake and being
able to make a bitbake branch available might actually be useful at the
moment. 

So I'm now moving to a position of strongly favouring git. 

Whilst I've argued against it in the past I would consider a move of
bitbake from svn to git too.

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Richard Purdie schreef:

| Whilst I think OE will always have a central master .dev repository I
| see a lot of gain from having branches. I would have happily put the
| sysroot changes into a branch and likewise the packaged-staging stuff
| I'm working on. As it is I'm keeping it locally uncommitted with no
| version tracking since I don't really want to play games with monotone.

Thank you for saying it right out: "I haven't tried to use branches in
mtn, ever".
So we only have Holger saying mtn can't merge the dreambox branch, and
people ignoring what I said about the avr32 branch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH2F89MkyGM64RGpERAt5yAKC4TXk04x3gf7MIooWMKYyH2qcqZQCgroTe
l2F7QyUkBClceQpoJ4cU/cI=
=ssbV
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Leon Woestenberg]

Hello,

On Wed, Mar 12, 2008 at 11:54 PM, Koen Kooi
<koen@dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  | Whilst I think OE will always have a central master .dev repository I
>  | see a lot of gain from having branches. I would have happily put the
>  | sysroot changes into a branch and likewise the packaged-staging stuff
>  | I'm working on. As it is I'm keeping it locally uncommitted with no
>  | version tracking since I don't really want to play games with monotone.
>
>  Thank you for saying it right out: "I haven't tried to use branches in
>  mtn, ever".
>
mtn will handle branches, no issue. But how easy can a branch be
merged back if it has been branching off for too long? I guess we end
up in the same situation as the dreambox branch?

Paul, *yes* a head is like a branch in the revision control system,
but I cannot use it as a branch! Unless you can explain me how I could
*easily track or pluck from* the AVR work if it wasn't branched but a
different head.

>  So we only have Holger saying mtn can't merge the dreambox branch, and
>  people ignoring what I said about the avr32 branch.
>
We would like to merge easily and branch cheaply. Obviously, mtn can
cope with the latter and lacks in the first. Is that alone enough to
move to hg or git?

I found this: http://utsl.gen.nz/talks/git-svn/intro.html, and I quote below:

What Mercurial (=Hg) has over git
=========================

Mercurial is missing lightweight branches that makes git so powerful,
and there is no content hashing, so it doesn't really do the whole
"revision protocol" thing like git. This is why people like Ted T'so
say "git has more legs".

However as a version control system in its own right, it's certainly
one of the best. And if you consider that it is almost a twin brother
of git, being written in response to Larry McVoy's Great Temper
Tantrum™ and its first release only a couple of weeks later than git's
first release, and given all that it has achieved, it's an outstanding
accomplishment.

Here are some of the reasons why.

Portability and Consistency

Mercurial, like Bazaar-NG, is written completely in Python (with some
performance critical parts in C). So, if you like Python you might
find that good. If you're on Windows it's probably a lot easier to get
going. Hey, maybe it will even one day run on IronPython on .NET.
Optimisation for the Cold Cache case

In the "cold cache" case, git typically needs to load a lot of blocks
to do some operations. Mercurial, on the other hand, gets away with
far fewer seeks for them. This means it can be a lot faster - for
instance, one use case that Mercurial is a lot faster is applying a
ton of patches.

In the "hot cache" case, git typically blows Mercurial out of the
water, except for operations where git is having to do searches to get
the data, like annotate.

Bundle efficiency

Mercurial's hg bundle does a really, really good job of making small
packs. With the e2fsprogs repository, it managed to make a pack that
was 50% smaller than the default git pack, and its default bundle was
20% smaller than an agressively (and expensively) packed git pack.


Regards,
-- 
Leon

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Wed, 2008-03-12 at 23:54 +0100, Koen Kooi wrote:
> Richard Purdie schreef:
> | Whilst I think OE will always have a central master .dev repository I
> | see a lot of gain from having branches. I would have happily put the
> | sysroot changes into a branch and likewise the packaged-staging stuff
> | I'm working on. As it is I'm keeping it locally uncommitted with no
> | version tracking since I don't really want to play games with monotone.
> 
> Thank you for saying it right out: "I haven't tried to use branches in
> mtn, ever".

That is not what I said. 

Branches in OE have stigma attached to them. Incidents like the zecke
branch that made it onto the server which we had trouble removing didn't
encourage people to experiment and personally I'm slightly paranoid
about what I do in case things end up outside my local system which
shouldn't. 

Steps may have been taken server side to reduce the chances of these
things making it in. If so, that means creating and sharing a branch
isn't easy (server side config has to be changed). If not, it means
creation of branches on our master server isn't restricted and that
could be an equal worry.

As for playing with branches, I did that as illustrated in the mail I
sent at the end of January with total failure as I couldn't do what I
needed. I have also played at other times but have never had enough
confidence to use them.

I appreciate we now have suspend certificates which would be useful for
solving some of the past problems and yes, the situation may be better
now but the branch support isn't comparable to that in git. I also
didn't know the main server supported suspend certificates until the
start of this thread!

I'm not actually that keen on git, monotone has just pushed too many of
us over the edge, me included and this time around I'd like to see
something in more widespread use being chosen. If you believe various
arguments, git and hg are heading for convergence so in the long run it
probably doesn't matter too much which we pick. Short term, git has
features I'd like to use hg doesn't have.

> So we only have Holger saying mtn can't merge the dreambox branch, and
> people ignoring what I said about the avr32 branch.

You basically said that if you hadn't run "mtn propagate" every X days
you would have had an unmergable mess? The dreambox branch is unmergable
because this hasn't been done? This isn't an example of the SCM working
well...

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Richard Purdie schreef:

| You basically said that if you hadn't run "mtn propagate" every X days
| you would have had an unmergable mess?

I didn't say that, because that isn't true

| The dreambox branch is unmergable because this hasn't been done?

Actually the dreambox branch *is* mergable once you fix up the
non-content conflicts[1].

How do you get a non-content conflict: a file gets added on both
branches seperately, so on each branch it gets a different node-id.
Solution: 'mtn mv' or 'mtn drop' the file.

What has happened in the dreambox branch: updates weren't done with
propagate, but by copying over files and 'mtn add -R ; mtn commit'-ing them.

The problem is that mtn developers fail to accept that silently merging
node-ids is OK when the *contents* are the same.

regards,

Koen

[1] there are a lot of them
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH2OtyMkyGM64RGpERAmKFAJwLaMVc8G9bJuiYu2R39e7uIsOCEgCgsS+N
4wJwVmPa50Rj5cDiTuebTV4=
=2ccG
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Florian Boor]

Hi,

Koen Kooi schrieb:
> The problem is that mtn developers fail to accept that silently merging
> node-ids is OK when the *contents* are the same.

... and even if the contents were not the same you could try a merge. These
things make mtn a bad choice. In combination with bad error handling it makes it
a pain.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Reconsidering the work flow and how the SCM system fits in

[Marcin Juszkiewicz]

Dnia Wednesday 12 of March 2008, Koen Kooi napisał:
> Richard Purdie schreef:
> | Whilst I think OE will always have a central master .dev repository I
> | see a lot of gain from having branches. I would have happily put the
> | sysroot changes into a branch and likewise the packaged-staging stuff
> | I'm working on. As it is I'm keeping it locally uncommitted with no
> | version tracking since I don't really want to play games with
> | monotone.
>
> Thank you for saying it right out: "I haven't tried to use branches in
> mtn, ever".
> So we only have Holger saying mtn can't merge the dreambox branch, and
> people ignoring what I said about the avr32 branch.

I maintained MTN branches for quite long time (.oz354fam083 and .oz345x). 
I did not merged them with .dev (as they were for other stuff) but only 
cherrypicked some revisions .dev <> .oz354x/.oz345fam083. 

There was one thing which I did not liked - MTN cared more about files and 
their history then about content of those files. I remember situations 
when it was not possible to cherrypick one line change because there was 
few revisions difference between .oz354x and .dev versions. 
Patching .oz354x by hand was the only solution then.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

     Free speech includes the right not to listen, if not interested 
                                                [Robert A. Heinlein]

Re: Reconsidering the work flow and how the SCM system fits in

[Rod Whitby]

Richard Purdie wrote:
> Whilst I've argued against it in the past I would consider a move of
> bitbake from svn to git too.

I'd like to see bitbake made part of the *same* repository, since 
bitbake and OE are so intimately linked, and no-one uses bitbake for 
anything other than OE, and no-one uses OE with anything other than bitbake.

-- Rod

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Thu, 2008-03-13 at 10:48 +1030, Rod Whitby wrote:
> Richard Purdie wrote:
> > Whilst I've argued against it in the past I would consider a move of
> > bitbake from svn to git too.
> 
> I'd like to see bitbake made part of the *same* repository, since 
> bitbake and OE are so intimately linked, and no-one uses bitbake for 
> anything other than OE, and no-one uses OE with anything other than bitbake.

As I've said before I'm dead set against this. Bitbake was split from OE
for good reason.

1. The code separation forces people to recognise the metadata and the
tool parsing it are two separate things. One of OE's problems in the
past has been the lack of clear definition between layers and keeping
them separate makes the boundaries clear.

2. Assuming we have more branches for OE in the future, having a
potentially different and incompatible copy of bitbake for each branch
is a really bad idea.

3. Bitbake is its own project with releases and branches. It can't do
that effectively if you combine it with OE. Different people use
different branches of bitbake with OE.dev.

4. Whilst its not happened, you could use bitbake for different metadata
and I would welcome anyone doing that.

I'm not adverse to people having branches where bitbake and OE metadata
are combined for ease of end user use, Poky would be an example. I agree
there is a problem if the end user has to download multiple tools as it
complicates the setup. I also agree the combining does create technical
challenges with updating but with poky it is literally a case of copying
the latest 1.8 release or sometimes 1.8 svn branch in.

If we produce stable release tarballs, merging in a copy of bitbake
would be something I'd support.

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Rod Whitby]

Richard Purdie wrote:
> On Thu, 2008-03-13 at 10:48 +1030, Rod Whitby wrote:
>> I'd like to see bitbake made part of the *same* repository, since 
>> bitbake and OE are so intimately linked, and no-one uses bitbake for 
>> anything other than OE, and no-one uses OE with anything other than bitbake.
> 
> As I've said before I'm dead set against this.

Fair enough.

> If we produce stable release tarballs, merging in a copy of bitbake
> would be something I'd support.

Yes, I think that's really what I'm asking for.  I agree with your 
reasons why it shouldn't be merged for .dev ...

-- Rod

Re: Reconsidering the work flow and how the SCM system fits in

[Hans Henry von Tresckow]

Since there seem to be at least two major schools of thought on which SCM to
use, has anybody condiddered some sort of hybrid approach? SSCM (
http://sscm.masukomi.org/) looks like an interesting tool to keep multiple
SCM's happy.

I think that the apparent bias towards git has something to do with the fact
that most people working on embedded hardware need to do a fair share of
kernel hacking.

I do agree that whatever solution we pick needs to allow for easier
branching-merging-backporting then the current mtn repo.

Just some random thoughts by a (for now) read-only OE user.


-- 
Henry von Tresckow (hvontres)

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Wed, 2008-03-12 at 20:00 +0100, Koen Kooi wrote:
> Actually it shows that hg fits better into the OE way of using a DSCM:
> central repo (and mirrors) with distributed developers.
> 
> I keep hearing people saying that they have no clue on how to setup a
> git-server for OE where we can commit things as usual, 

Thats not quite true, we've just wondered what the best way to do it
is...

> while with hg it's just 'hg serve'.

How do two hg servers interact?

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Richard Purdie schreef:
| On Wed, 2008-03-12 at 20:00 +0100, Koen Kooi wrote:

|> while with hg it's just 'hg serve'.
|
| How do two hg servers interact?

I don't get your question, could you eloborate?

regards,

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

iD8DBQFH2ElGMkyGM64RGpERAvLKAJ94PxByRDSLvbQtfSmYI3bGiACTIACdFrGo
h8FclSaB5g85DMCt4y5E/m0=
=B9Vq
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Wed, 12 Mar 2008 22:21:10 +0100
Koen Kooi <koen@dominion.kabel.utwente.nl> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Richard Purdie schreef:
> | On Wed, 2008-03-12 at 20:00 +0100, Koen Kooi wrote:
> 
> |> while with hg it's just 'hg serve'.
> |
> | How do two hg servers interact?
> 
> I don't get your question, could you eloborate?

Actually, that's big and important question, which I keep putting off
to raise, trying to grasp other issues.

With mtn we seem to have very cheap and robust mirroring and
high-availability. Well, any DSCM lean on possibility of easy
mirroring, but Monotone with its super-cool concept of unbelievably
cheap branches (so-called heads), make it just well robust - even if
two different servers conflicting changes were made, they still can
synchronize without slightest issue and have both sets of changes, for
a human to resolve conflict at arbitrary point later.

I have to admit that I have no idea how any other DSCM would behave
regarding that.

> 
> regards,
> 
> Koen
[]


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Leon Woestenberg]

Hello Paul,

On Wed, Mar 12, 2008 at 10:40 PM, Paul Sokolovsky <pmiscml@gmail.com> wrote:
>  mirroring, but Monotone with its super-cool concept of unbelievably
>  cheap branches (so-called heads), make it just well robust - even if
>
Multiple heads and lightweight branches are two different things.

A branch has a name/tag that tells me what is happening in that branch
or who is making it happen.

In contrast, multiple heads does not help me in any way as a tool for
branching, nor can I easily track someone else's work in his "head".

Regards,
-- 
Leon

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Wed, 12 Mar 2008 23:07:03 +0100
"Leon Woestenberg" <leon.woestenberg@gmail.com> wrote:

> Hello Paul,
> 
> On Wed, Mar 12, 2008 at 10:40 PM, Paul Sokolovsky <pmiscml@gmail.com>
> wrote:
> >  mirroring, but Monotone with its super-cool concept of unbelievably
> >  cheap branches (so-called heads), make it just well robust - even
> > if
> >
> Multiple heads and lightweight branches are two different things.

Probably also because of different numbers of hexadecimal digits?

> 
> A branch has a name/tag that tells me what is happening in that branch
> or who is making it happen.

And heads have head revision and change logs too!

> 
> In contrast, multiple heads does not help me in any way as a tool for
> branching, nor can I easily track someone else's work in his "head".

That's because you've stuck with that old and boring concept of
"lightweight branches". People who grasped heads novelty enjoy it very
much. Well, the same can be said about the people who didn't drop
everything to endeavor into those "lightweight branches" - they enjoy
classy branches with not the lesser passion than the other two groups.


Well, but the talk was about mirroring and syncing potentially
incompatible changes. Do lightweight branches help with this?

> 
> Regards,
> -- 
> Leon

[]


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Marcin Juszkiewicz]

Dnia Wednesday 12 of March 2008, Paul Sokolovsky napisał:
> "Leon Woestenberg" <leon.woestenberg@gmail.com> wrote:

> > Multiple heads and lightweight branches are two different things.
>
> Probably also because of different numbers of hexadecimal digits?
>
> > A branch has a name/tag that tells me what is happening in that
> > branch or who is making it happen.
>
> And heads have head revision and change logs too!

And gets automerged by our monotone server.

> Well, but the talk was about mirroring and syncing potentially
> incompatible changes. Do lightweight branches help with this?

They do. After Poky release I pushed lot of stuff which I had ready on my 
harddisk (unversioned). With GIT I would just do 'poky-after-3.1-release' 
branch which would die after merging with 'trunk'.

For making experiments with Poky I can create branch (via git-svn for now) 
which will have few days of work inside which will then be merged and 
pushed.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

                 We are the Knights who say: MOVE.L USP,A1

Re: Reconsidering the work flow and how the SCM system fits in

[Justin Patrin]

2008/3/13 Marcin Juszkiewicz <openembedded@haerwu.biz>:
> Dnia Wednesday 12 of March 2008, Paul Sokolovsky napisał:
>
> > "Leon Woestenberg" <leon.woestenberg@gmail.com> wrote:
>
>
> > > Multiple heads and lightweight branches are two different things.
>  >
>  > Probably also because of different numbers of hexadecimal digits?
>  >
>  > > A branch has a name/tag that tells me what is happening in that
>  > > branch or who is making it happen.
>  >
>  > And heads have head revision and change logs too!
>
>  And gets automerged by our monotone server.
>
>
>  > Well, but the talk was about mirroring and syncing potentially
>  > incompatible changes. Do lightweight branches help with this?
>
>  They do. After Poky release I pushed lot of stuff which I had ready on my
>  harddisk (unversioned). With GIT I would just do 'poky-after-3.1-release'
>  branch which would die after merging with 'trunk'.
>
>  For making experiments with Poky I can create branch (via git-svn for now)
>  which will have few days of work inside which will then be merged and
>  pushed.
>

Which you can also do with mtn. Make a local branch, make your
changes, commit them locally. When you sync/push your local branch
won't be pushed to the server. When you're finished simply propagate
back to the master branch (.dev). When you next sync/push your local
revisions will go up as they are ancestors of the propagate but the
branch certs won't since the server doesn't allow that branch. Not
only do you have your own local branch which is never pushed to the
server, but you also get to keep each ofyour commits. More revision
history, more commit messages, more insight into development. Of
course, your local database still has the branch certs for you local
branch. If you want to get rid of these there are commands that will
remove them that are surely no mor ecomplicated than most of git's
commands.

-- 
Justin Patrin

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Wed, 2008-03-12 at 22:21 +0100, Koen Kooi wrote:
> Richard Purdie schreef:
> | On Wed, 2008-03-12 at 20:00 +0100, Koen Kooi wrote:
> 
> |> while with hg it's just 'hg serve'.
> |
> | How do two hg servers interact?
> 
> I don't get your question, could you eloborate?

How does the hg server on oe.org interact with the one nslu2 or any
other project may setup?

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

Twas brillig at 21:11:30 12.03.2008 UTC+00 when Richard Purdie did gyre and gimble:

 >> while with hg it's just 'hg serve'.
 RP> How do two hg servers interact?

They don't. It's a pull-, not push-model.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: Reconsidering the work flow and how the SCM system fits in

[Dmitry Nezhevenko]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On Thu, Mar 13, 2008 at 03:37:34AM +0600, Mikhail Gusarov wrote:
> Twas brillig at 21:11:30 12.03.2008 UTC+00 when Richard Purdie did gyre and gimble:
> 
>  >> while with hg it's just 'hg serve'.
>  RP> How do two hg servers interact?
> 
> They don't. It's a pull-, not push-model.
> 

However it's possible to create hook that will send command to remote
server after repository update (for example via ssh with public-key auth.)
to pull changes from master.

-- 
WBR, Dmitry

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: Reconsidering the work flow and how the SCM system fits in

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 278 bytes --]

Twas brillig at 11:25:59 11.03.2008 UTC+01 when Marcin Juszkiewicz did gyre and gimble:

 >> - I lack a GUI to easily browse the repository

 MJ> Does Mercurial has such one? GIT has gitk, qgit and probably
 MJ> something more.

'hg view' is direct port of gitk.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Tue, 2008-03-11 at 08:07 +0100, Holger Freyther wrote:
> I'm anything but happy with the way we work with our repository. We have a 
> dreambox branch that is not mergable due issues with our SCM system, the 
> OpenMoko guys have to go back to diffing and applying the diff and merging by 
> hand, we just commit fundamental changes like sysroot, packaged-staging, RFCs 
> in one go and then do weeks of fixing. And I can continue with this list.
[...]
> I think the two options are hg and git, I tend to favor git due the size of 
> its community. I want to switch OE to one of these systems by the end of this 
> month and start using more branches and creating perfect patch series again.

Thanks for raising this, I think one by one we're all getting frustrated
with monotone as my email at the end of January showed in my case.

One major concern I have is the amount of 'pointless' merging we're
doing. Each developers commits should just have a maximum of one merge
at the end of each commit series and we have way more than that going
on.

I also worry that we don't have decent visualisation tools with monotone
and our website is often broken. By contrast http://git.o-hand.com/ has
worked since I set it up and there are alternatives out there too for
git (competition is good).

I don't think git is the perfect SCM, its syntax is insane. I do think
its powerful and now has widespread enough use creating a momentum that
monotone never had. I also think you could write a nice UI around it,
the backend is sound and I remain optimistic this will happen in time.

I don't really know hg but to me thats a good reason to favour git, its
has a bigger userbase. I'd not like to see OE making the "mistake" we
made with monotone and picking something which isn't widely understood
or used :/.

My concern with git is how we'll run the server. OH has been thinking
about using git but the server setup is tricky for "push" access which
is the model OE would use. The two choices seem to be ssh or webdav and
the latter isn't something I've found time to look into setting up but
people keep telling me its possible.

Anyhow, my vote is for git...

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Graeme Gregory]

On Tue, 11 Mar 2008 10:53:41 +0000
Richard Purdie <rpurdie@rpsys.net> wrote:
> My concern with git is how we'll run the server. OH has been thinking
> about using git but the server setup is tricky for "push" access which
> is the model OE would use. The two choices seem to be ssh or webdav
> and the latter isn't something I've found time to look into setting
> up but people keep telling me its possible.
> 
There is somewhere a method of running git using ssh auth, but without
granting shell access. Im sure some searching would turn it up.

But basically this mode is no different than the mtn setup we use
already. Just a different source of private key.

Graeme

Re: Reconsidering the work flow and how the SCM system fits in

[Florian Boor]

Hi,

Graeme Gregory schrieb:
> There is somewhere a method of running git using ssh auth, but without
> granting shell access. Im sure some searching would turn it up.

it should work like for svn: Use a special login shell for the users that are
expected to use the access for scm purposes only. You could even use GForge to
manage users and permissions.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Reconsidering the work flow and how the SCM system fits in

[Florian Boor]

Hello,

Holger Freyther schrieb:
> I'm anything but happy with the way we work with our repository. We have a 
> dreambox branch that is not mergable due issues with our SCM system, the 
> OpenMoko guys have to go back to diffing and applying the diff and merging by 
> hand, we just commit fundamental changes like sysroot, packaged-staging, RFCs 
> in one go and then do weeks of fixing. And I can continue with this list.

agreed, looking at other projects it becomes clear that we could do much better.

> What: I think we should use more branches
> 	- As many shortlived and medium lived branches as developers want
> 	- Shared branches for stuff like packaged staging, RFCs, sysroot. Were you
> 	  start the development, add features, other people will compile their stuff, 
> 	  other compile and then you rebase and merge!
> 	- Basicly you develop a feature in a branch until it is ready and not 
> 	  impacting other things, then you rebase/cleanup, propose it for inclusion 
> 	  and wait for feedback, then merge.
> 	- Stable distributions and vendors get their own branch, they can merge, 
> 	  cherry-pick what ever they want.

This implies a similar workflow like for the Linux kernel development. With
working tools a good idea. The only disadvantage I see is that a major share of
the developers (including myself) might not be used to this yet. But I would be
fine with that.

> The issue:
> 	- mtn can not merge. Forcing me to manually delete files in one copy to do a 
> 	  merge is not acceptable.

That's the major drawback of mtn - even CVS is better resolving conflicts.
Another major issue is the missing support for atomic operations. If an update
fails it happens that you end up in an undefined state where it is hard or even
impossible to recover from.

> I want that we use more branches for development, apply review on them, 
> land/merge/push these branches after review, pull peoples changes from other 
> hosts, work on perfetch patch series before landing patches. I believe we 
> need to deploy this kind of development in OE again and as mtn is the 
> obstacle to this kind of development I propose to switch to another SCM 
> system that allows us to develop OpenEmbedded the way it should be developed.

It would reduce the effort for maintaining a kind of 'testing' branch (in the
sense of Debian testing) where we put in stuff that is quite up to date but
basically tested.

> My criteria:
> 	- Should have branches, easy merging, easy merging of merges
> 	- Branches and merging should be cheap
Yes, very important.

> 	- Make it easy to put the OE tree into another SCM and still be able
> 	  to merge (git-svn and such)
that's another good point - OE is used as a tool for other projects who might
have decided for a different SCM before (e.g. OpenMoko and Poky). This would
make it much easier to integrate their work with OE and merge back changes.
For OE I would see this as a one of the key features the SCM must have.

> I think the two options are hg and git, I tend to favor git due the size of 
> its community. I want to switch OE to one of these systems by the end of this 
> month and start using more branches and creating perfect patch series again.

I do not think there are more candidates, but even deciding for one of these is
hard. :-} Do we have a good comparison between these somewhere?

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Reconsidering the work flow and how the SCM system fits in

[Mike (mwester)]

[top posting to save readers time]

+100 from me (can I do that?) --- as a long time SCM proponent (SCM 
consulting has clothed and fed my family and put a roof over our heads 
for many years), I am hugely in favor of switching to another tool and 
using features such as branching!

I haven't used git myself, but from what I've read, it seems to be the 
logical choice, so I concur with that choice as well.

(It would be so incredible to have a proper tool for branching and 
merging - this would make me rather happy!)

Mike (mwester)



Holger Freyther wrote:
> Hey,
> 
> I'm anything but happy with the way we work with our repository. We have a 
> dreambox branch that is not mergable due issues with our SCM system, the 
> OpenMoko guys have to go back to diffing and applying the diff and merging by 
> hand, we just commit fundamental changes like sysroot, packaged-staging, RFCs 
> in one go and then do weeks of fixing. And I can continue with this list.
> 
> What: I think we should use more branches
> 	- As many shortlived and medium lived branches as developers want
> 	- Shared branches for stuff like packaged staging, RFCs, sysroot. Were you
> 	  start the development, add features, other people will compile their stuff, 
> 	  other compile and then you rebase and merge!
> 	- Basicly you develop a feature in a branch until it is ready and not 
> 	  impacting other things, then you rebase/cleanup, propose it for inclusion 
> 	  and wait for feedback, then merge.
> 	- Stable distributions and vendors get their own branch, they can merge, 
> 	  cherry-pick what ever they want.
> 
> 
> The issue:
> 	- mtn can not merge. Forcing me to manually delete files in one copy to do a 
> 	  merge is not acceptable.
> 	- mtn has not the concept of short-lived branches (e.g. deleting their 
> 	  existence once done), mtn suspend does not work as witnessed by our 
> 	  automerger.
> 	- mtn pluck is not making me happy
> 	- I lack a GUI to easily browse the repository
> 	- I can not clean up changes before I push them!
> 
> 
> I want that we use more branches for development, apply review on them, 
> land/merge/push these branches after review, pull peoples changes from other 
> hosts, work on perfetch patch series before landing patches. I believe we 
> need to deploy this kind of development in OE again and as mtn is the 
> obstacle to this kind of development I propose to switch to another SCM 
> system that allows us to develop OpenEmbedded the way it should be developed.
> 
> My criteria:
> 	- Should have branches, easy merging, easy merging of merges
> 	- Branches and merging should be cheap
> 	- Make it easy to put the OE tree into another SCM and still be able
> 	  to merge (git-svn and such)
> 	- A good graphical tool to browse the repository
> 	- A good and maintained web frontend
> 	- A good set of builtin tools (e.g. like git-add -i and git-rebase -i)
> 
> I think the two options are hg and git, I tend to favor git due the size of 
> its community. I want to switch OE to one of these systems by the end of this 
> month and start using more branches and creating perfect patch series again.
> 
> 
> comments? agreement?
> 
> 	z.
> 
> 
> PS: It is not the speed of mtn, it is the lack of development in areas like 
> branches, merging, rebasing, we need to use these in OE!
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

Re: Reconsidering the work flow and how the SCM system fits in

[Mike Westerhof]

On Wed 12/03/08  2:00 PM , Koen Kooi koen@dominion.kabel.utwente.nl sent:

> I keep hearing people saying that they have no clue on how to setup a
> git-server for OE where we can commit things as usual, while with hg
> it's just 'hg serve'.

How many people _NEED_ to know how to set up a server, versus how many people
need to know how to use the client tools?  I think the availability of
end-user-assistance needs to be a prime consideration, lest we end up as we are
now -- where every newbie ends up on the IRC channel asking for help on what
should be simple operations.

> regards,
> 
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
> iD8DBQFH2Cg6MkyGM64RGpERArCvAJ0ZOXNRysB3/I5HNJwuhto25TrXAQCffaad
> VD7lvC0aO123KP3MOPDtweU=
> =aHj0
> -----END PGP SIGNATURE-----

Mike (mwester)

Re: Reconsidering the work flow and how the SCM system fits in

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

Twas brillig at 15:34:49 12.03.2008 UTC-05 when Mike Westerhof did gyre and gimble:

 MW> How many people _NEED_ to know how to set up a server, versus how
 MW> many people need to know how to use the client tools?

Everyone who wants to publish changes.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: Reconsidering the work flow and how the SCM system fits in

[Rodrigo Vivi]

How to setup a git server over http:

hhtp: http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt

How to public git repositories:

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#public-repositories

On Wed, Mar 12, 2008 at 5:47 PM, Mikhail Gusarov
<dottedmag@dottedmag.net> wrote:
> Twas brillig at 15:34:49 12.03.2008 UTC-05 when Mike Westerhof did gyre and gimble:
>
>   MW> How many people _NEED_ to know how to set up a server, versus how
>   MW> many people need to know how to use the client tools?
>
>  Everyone who wants to publish changes.
>
>  --
>
> _______________________________________________
>  Openembedded-devel mailing list
>  Openembedded-devel@lists.openembedded.org
>  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>



-- 
Rodrigo Vivi
INdT - Instituto Nokia de Tecnologia
Blog: http://blog.vivi.eng.br
GPG: 0x905BE242 @ wwwkeys.pgp.net

Re: Reconsidering the work flow and how the SCM system fits in

[Koen Kooi]

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

Rodrigo Vivi schreef:
| How to setup a git server over http:
|
| hhtp:
http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
|
| How to public git repositories:
|
|
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#public-repositories

So either apache or sshd, which means you can't setup a 'server' quickly
during e.g. a conference.

regards,

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

iD8DBQFH2EkQMkyGM64RGpERAo+5AJ9yxFrvUjQ2Vu2sgFcKaF2XfufLGACgn293
OCJ75i8jvLPuyvS/HCbHQe4=
=MWen
-----END PGP SIGNATURE-----

Re: Reconsidering the work flow and how the SCM system fits in

[Mark Brown]

On Wed, Mar 12, 2008 at 10:20:16PM +0100, Koen Kooi wrote:

> So either apache or sshd, which means you can't setup a 'server' quickly
> during e.g. a conference.

Yes, git has nothing matching the single commands of mtn or hg if you
need to set up a temporary server in a hurry.

If you're looking for something you can do instantly on your laptop or
similar then serving it over git:// might do the job but it requires
inetd and flipping a switch to enable unauthenticated access:

  http://www.kernel.org/pub/software/scm/git/docs/everyday.html#Repository%20Administration

If you're actually talking to the person you're trying to share with
(presumably if you don't have sensible net access) there's also the
option of using a SSH server on your laptop (possibly in conjunction
with git-shell) to give them read-only access.

You can also just copy the entire repo to a machine, though that's not
going to be the most efficient thing in the world.  There's also the
option of using git-send-email plus git-am if you can transmit over
mail, but that's not guaranteed either and not everyone's mail setup can
deal with large volumes of patches gracefully.

Like I say, none of these options quite match the server options of hg
or mtn.

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

Re: Reconsidering the work flow and how the SCM system fits in

[Mike Westerhof]

 On Wed 12/03/08  4:40 PM , Paul Sokolovsky pmiscml@gmail.com sent:
...
> With mtn we seem to have very cheap and robust mirroring and
> high-availability. Well, any DSCM lean on possibility of easy
> mirroring, but Monotone with its super-cool concept of unbelievably
> cheap branches (so-called heads), ...

Hehe! Yes, and I could describe an automobile spinning out-of-control on a patch of ice as "unbelievably cheap steering" just as well.  Let's not overlook the fact that the multiple-heads issue with monotone is very seldom because the person doing it *wished* for that to happen.

> 
> -- 
> Best regards,
> Paul                          pmiscml@gma
> il.com

Mike (mwester)

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Wed, 12 Mar 2008 17:03:13 -0500
Mike Westerhof <mwester@dls.net> wrote:

>  On Wed 12/03/08  4:40 PM , Paul Sokolovsky pmiscml@gmail.com sent:
> ...
> > With mtn we seem to have very cheap and robust mirroring and
> > high-availability. Well, any DSCM lean on possibility of easy
> > mirroring, but Monotone with its super-cool concept of unbelievably
> > cheap branches (so-called heads), ...
> 
> Hehe! Yes, and I could describe an automobile spinning out-of-control
> on a patch of ice as "unbelievably cheap steering" just as well.
> Let's not overlook the fact that the multiple-heads issue with
> monotone is very seldom because the person doing it *wished* for that
> to happen.

Vice-versa, as was noted already, we have separate head created
almost on each commit (i.e. mtn merge almost always has something to
do on each run after commit). So, can one imagine more lightweight
branches - they are being created even without any explicit command!
Poor git is left far behind with its heavy branch commands! ;-D

> 
> > 
> > -- 
> > Best regards,
> > Paul                          pmiscml@gma
> > il.com
> 
> Mike (mwester)

[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Justin Patrin]

On Wed, Mar 12, 2008 at 3:21 PM, Paul Sokolovsky <pmiscml@gmail.com> wrote:
> Hello,
>
>
>  On Wed, 12 Mar 2008 17:03:13 -0500
>  Mike Westerhof <mwester@dls.net> wrote:
>
>  >  On Wed 12/03/08  4:40 PM , Paul Sokolovsky pmiscml@gmail.com sent:
>  > ...
>  > > With mtn we seem to have very cheap and robust mirroring and
>  > > high-availability. Well, any DSCM lean on possibility of easy
>  > > mirroring, but Monotone with its super-cool concept of unbelievably
>  > > cheap branches (so-called heads), ...
>  >
>  > Hehe! Yes, and I could describe an automobile spinning out-of-control
>  > on a patch of ice as "unbelievably cheap steering" just as well.
>  > Let's not overlook the fact that the multiple-heads issue with
>  > monotone is very seldom because the person doing it *wished* for that
>  > to happen.
>
>  Vice-versa, as was noted already, we have separate head created
>  almost on each commit (i.e. mtn merge almost always has something to
>  do on each run after commit). So, can one imagine more lightweight
>  branches - they are being created even without any explicit command!
>  Poor git is left far behind with its heavy branch commands! ;-D
>

And just to add insult to injury, this also points out that mtn also
merges very well, with no extra help. The non-content conflicts which
are trotted out again and again are due more to incorrect use of mtn
(read: not reading documentation) than to any problems in mtn itself.
It really depends on what you want. Reliable, correct, and impeccable
revision history or history through interchange of patches with an
implicit web of trust.

-- 
Justin Patrin

Re: Reconsidering the work flow and how the SCM system fits in

[Mike Westerhof]

 On Wed 12/03/08  5:32 PM , Paul Sokolovsky pmiscml@gmail.com sent:
> Hello,
> 
> On Wed, 12 Mar 2008 23:07:03 +0100
> "Leon Woestenberg" le
> on.woestenberg@gmail.com> wrote:
> > Hello Paul,
> > 
> > On Wed, Mar 12, 2008 at 10:40 PM, Paul Sokolovsky pmiscml@gma
> il.com>> wrote:
> > >  mirroring, but Monotone with its super-cool concept
> of unbelievably> >  cheap branches (so-called heads), make it just well
> robust - even> > if
> > >
> > Multiple heads and lightweight branches are two
> different things.
> Probably also because of different numbers of hexadecimal digits?
> 
> > 
> > A branch has a name/tag that tells me what is happening
> in that branch> or who is making it happen.
> 
> And heads have head revision and change logs too!
> 
> > 
> > In contrast, multiple heads does not help me in any way
> as a tool for> branching, nor can I easily track someone else's work
> in his "head".
> That's because you've stuck with that old and boring concept of
> "lightweight branches". People who grasped heads novelty enjoy it very
> much. Well, the same can be said about the people who didn't drop
> everything to endeavor into those "lightweight branches" - they enjoy
> classy branches with not the lesser passion than the other two groups.
> 
> 
> Well, but the talk was about mirroring and syncing potentially
> incompatible changes. Do lightweight branches help with this?
> 
> > 
> > Regards,
> > -- 
> > Leon
> 
> []
> 
> 
> -- 
> Best regards,
> Paul                          pmiscml@gma
> il.com

I think this has gotten to the point where the arguments is for the sake of arguing, and little else.  I'm surprised that it hasn't been mentioned that "hg" has the advantage that its name is only two characters, a 33% savings in overhead compared to most other scm tools we've discussed.


So, who makes this decision, and what's the timeframe?

Mike  (mwester)

Oh - btw, lightweight branching implies working, reliable tools to identify diffs and merge them, that's the part that really needs to be considered rather than how easy it is to just create a branch.

Re: Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Wed, 12 Mar 2008 17:48:51 -0500
Mike Westerhof <mwester@dls.net> wrote:

[]

> I think this has gotten to the point where the arguments is for the
> sake of arguing, and little else.  

Maybe, and on git's side, there's surprisingly little variety of
arguments - 1) "it has lightweight branches" (hg has too, as was pointed
out, but as plugin (which is good) of experimental state (with
obvious entailments)); 2) "I use git, and it works well for me" - it's
hard to respond without calling CVS ghost; 3) "Don't make people learn
more stuff" - and nobody appears to care about people who *don't* know
git - there're still more such potential OE users - is it fair to force
them to learn its quirks, or leave out people who don't want to learn
quirks?

> I'm surprised that it hasn't been
> mentioned that "hg" has the advantage that its name is only two
> characters, a 33% savings in overhead compared to most other scm
> tools we've discussed.

Actually, there's almost noone argues for hg too insistently. Mostly,
there're calls to think better about git.

> So, who makes this decision, and what's the timeframe?

Apparently, core team? Original proposal named end of month?

> 
> Mike  (mwester)
> 
> Oh - btw, lightweight branching implies working, reliable tools to
> identify diffs and merge them, that's the part that really needs to
> be considered rather than how easy it is to just create a branch.

Aha, good. But not only that. We really should think are lightweight
branches so useful for OE, and do they really fit well into *our*
*current* infrastructure.

[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Reconsidering the work flow and how the SCM system fits in

[Richard Purdie]

On Wed, 2008-03-12 at 17:48 -0500, Mike Westerhof wrote:
> I think this has gotten to the point where the arguments is for the
> sake of arguing, and little else.  I'm surprised that it hasn't been
> mentioned that "hg" has the advantage that its name is only two
> characters, a 33% savings in overhead compared to most other scm tools
> we've discussed.

Agreed, some of the replies are just getting silly now :/.

> So, who makes this decision, and what's the timeframe?

Good question. We have a core team and I guess the first step would be
to put it to a vote there and see where we stand? I'm open to other
ideas and possibly to representations from non core team developers with
a case for a vote too. I would like to get this resolved quickly if we
can though.

Timeframe wise, I liked Holger's end of the month deadline for actually
doing things.

> Oh - btw, lightweight branching implies working, reliable tools to
> identify diffs and merge them, that's the part that really needs to be
> considered rather than how easy it is to just create a branch.

Agreed, although Holger has already compared git's merging capabilities
to monotone...

Cheers,

Richard

Re: Reconsidering the work flow and how the SCM system fits in

[Rod Whitby]

Richard Purdie wrote:
> We have a core team and I guess the first step would be
> to put it to a vote there and see where we stand? I'm open to other
> ideas and possibly to representations from non core team developers with
> a case for a vote too.

The nslu2-linux project votes for git, for the following reasons:

1) Most of the nslu2 core team developers are already exposed to git due 
to kernel work.  None of them that I know of are exposed to hg.  Yes, 
that's a selfish position, and yes that means that we're arguing from a 
position of ignorance with respect to hg.

2) None of the nslu2 core team developers have the bandwidth to learn 
yet another SCM, purely for OE.  OE is a means to an end, not an end in 
itself.  Yes, that's a selfish position.

3) Git can support the multiple disconnected-but-syncing servers that 
currently exist in the way that monotone.nslu2-linux.org and 
monotone.openembedded.org work.  We cannot accept a single central 
server model, and I haven't seen anyone state how hg supports the 
multiple equal servers model yet.  But even if hg can support that 
model, we've already dealt with multiple git servers and know how that 
works, so we'd prefer not to need to set up a new system.  Yes, that's a 
selfish position.

4) All arguments against git so far seem to be either "an old version of 
git ate my data" or "git used to be poorly documented".  None of these 
arguments presented seem to be valid going forward in my opinion.

5) I've personally used git, and it does everything I would need it to 
do for OE development.  I haven't used hg, and prefer not to need to 
learn it, even if it did turn out to be technically better.  Yes, that's 
a selfish position.

So the summary is:

Git is good enough, we already use it, so let's just use it for one more 
purpose and get on with the real work.

-- Rod