Git versus Hg

Git versus Hg

[Philip Balister]

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

Given the only serious contenders for possible SCM's for OE appear to be 
git or Hg, I am curious about the expertise level available on this list.

Basically, let us know if you use git or Hg on a regular basis in a two 
way workflow and consider yourself knowledgeable on sorting out problems 
that crop up.

Philip

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

Re: Git versus Hg

[Khem Raj]

I use git more than hg but they both are same for me.

On Tue, Mar 11, 2008 at 4:53 PM, Philip Balister <philip@balister.org> wrote:
> Given the only serious contenders for possible SCM's for OE appear to be
> git or Hg, I am curious about the expertise level available on this list.
>
> Basically, let us know if you use git or Hg on a regular basis in a two
> way workflow and consider yourself knowledgeable on sorting out problems
> that crop up.
>
> Philip
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>

Re: Git versus Hg

[Esben Haabendal]

I use git for kernel and U-Boot work, and is very happy with it. I am
especially happy with its branching features where I regularly work with
multiple remote and local branches in the same project.

I have never tried Hg.

/Esben

On Wed, Mar 12, 2008 at 12:53 AM, Philip Balister <philip@balister.org>
wrote:

> Given the only serious contenders for possible SCM's for OE appear to be
> git or Hg, I am curious about the expertise level available on this list.
>
> Basically, let us know if you use git or Hg on a regular basis in a two
> way workflow and consider yourself knowledgeable on sorting out problems
> that crop up.
>
> Philip
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>

Re: Git versus Hg

[pHilipp Zabel]

On Wed, Mar 12, 2008 at 12:53 AM, Philip Balister <philip@balister.org> wrote:
> Given the only serious contenders for possible SCM's for OE appear to be
>  git or Hg, I am curious about the expertise level available on this list.
>
>  Basically, let us know if you use git or Hg on a regular basis in a two
>  way workflow and consider yourself knowledgeable on sorting out problems
>  that crop up.

I have Hg installed since the last round of SCM discussion but never
used it seriously.
My git experience is mainly restricted to porcelain (add commit rebase
cherry-pick, etc.).
I'm using it for kernel work and for a handful of local repositiories
with linear history.

As I'm working under what one could today call serious resource
constraints (laptop w/ one 60GB hdd), git clone --reference and inline
branches are important features to me. And besides catching up with
mainline linux, git-rebase -i gives me the ability to check in every
stupid thought and easily clean up once I'm satisfied, whereas with
monotone I currently have to experiment outside of version control.

What is still unclear to me is how well a shared git repository with
push access for multiple parties is going to work. The mobile-linux
repository on serenity had some kind of permission trouble before we
added the group permission fixup in the post-update hook.

regards
Philipp

Re: Git versus Hg

[Rodrigo Vivi]

>  What is still unclear to me is how well a shared git repository with
>  push access for multiple parties is going to work. The mobile-linux
>  repository on serenity had some kind of permission trouble before we
>  added the group permission fixup in the post-update hook.

Very well. We have a Mamona git repository and each developer has
published their own repositories (sometimes with push access) and it
works fine. Using git remote you can add others branches fetching
pulling and pushing on them through http or ssh. For this you can
create a published branch your publish master and create another
branch to work on...
Git multiple branches is so amazing... It has almost no cost to create
or switch branches... Furthermore you can switch to a remote branch
and see your cowork branch as well use it to do a OE build.
And once more: git fetch and branch switch are *so fast*.

Cheers
vivijim

>  regards
>  Philipp
>
>
>
>  _______________________________________________
>  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: Git versus Hg

[Cliff Brake]

On Tue, Mar 11, 2008 at 7:53 PM, Philip Balister <philip@balister.org> wrote:
> Given the only serious contenders for possible SCM's for OE appear to be
>  git or Hg, I am curious about the expertise level available on this list.
>
>  Basically, let us know if you use git or Hg on a regular basis in a two
>  way workflow and consider yourself knowledgeable on sorting out problems
>  that crop up.

I use git regularly for kernel and u-boot development, and have
managed to get a flow going with multiple public repositories where
developers pull from public repositories.  This all works very well.
I have not set up a shared public repository yet, but will give it a
try to see how it works as I could use that capability that with a
current project.

Mercurial looks very interesting and nice in many aspects, but I have
not used it yet.  It seems to me one of the fundamental differences is
the concept of cheap/easy local branches.  Mercurial is working on
something like that
(http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches), but
it is obviously not central to its philosophy like git .  The idea of
creating many local branches a normal port of your development
workflow seems unique to git.  As the gitmagic link below states, it
makes it very easy to switch context to fix a bug, and then resume
work on another feature.  This is a lot more than just "being good at
generating patches"; it is a change in the way we work.  The ability
to manage cheap local branches caries with it some additional
complexities that may be part of the reason git is a little difficult
to understand when it comes to mirroring branches, etc.  To me, it
seems local branching is a central technical issue as it affects
developer workflow.  Comparing superficial things like the UI seems
secondary.  Many developers can't see this as it is difficult to
change the way we work once we get used to something.  git-stash is
another feature of git that adds to its capability to easily switch
context and fix a bug, etc.  The first time I watched Linus's talk on
git, I did not understand this.  But, after using git for a few months
it makes a lot more sense.

Some more information on git branches:
http://reddit.com/r/programming/info/69qe8/comments/c039eef
http://www-cs-students.stanford.edu/~blynn/gitmagic/ch04.html
http://mjtsai.com/blog/2007/07/15/subversion-to-git/
http://www.dribin.org/dave/blog/archives/2007/12/30/why_mercurial/
http://utsl.gen.nz/talks/git-svn/intro.html#howto-branch

So, in summary it seems that if developers are not interested in using
local branches in their personal development workflow, mercurial may
be a better choice (for technical reasons) as it is easier to use, has
lots of nice features for a more conventional distributed VCS flow.
But, if you want to utilize a workflow that leverages local branches
(which is a radical change), then git may be a better choice as it is
designed around this feature.  OE development (from a workflow
perspective) has not really been highly distributed in the past, so
perhaps git is overkill.  But, I still can't seem to overlook the
benefits to personal workflow that git branches offer.  That said, I
don't have any mercurial experience, and I would have to use it with a
real project to understand its advantages.

Cliff

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

Re: Git versus Hg

[Koen Kooi]

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

Cliff Brake schreef:

| Mercurial looks very interesting and nice in many aspects, but I have
| not used it yet.  It seems to me one of the fundamental differences is
| the concept of cheap/easy local branches.  Mercurial is working on
| something like that
| (http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches), but
| it is obviously not central to its philosophy like git .  The idea of
| creating many local branches a normal port of your development
| workflow seems unique to git.  As the gitmagic link below states, it
| makes it very easy to switch context to fix a bug, and then resume
| work on another feature.  This is a lot more than just "being good at
| generating patches"; it is a change in the way we work.

I can see how that's a good thing for what I call "traditional
application development" where a bunch of source files get compiled into
a single application (kernel, u-boot, xserver etc) where working on
multiple things at once doesn't work, since it makes building and
testing a nightmare. Easy branching solves that.

But OE isn't like that, it's a collection of build descriptions, which
makes it possible to be working on a 1000 different recipes at the same
time. This also is one of the reasons why mtn is so slow for us: lots of
files with a shortlived life spam and ±30 commits per day.

I like hg so much because it's the svn to monotones cvs: virtually
identical UI, without the crap.

regards,

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

iD8DBQFH1+h9MkyGM64RGpERAjc6AKCF0CIEIJml44MVR8xhuCxw4PwHIACfSnMh
rMWrhQTsv+0T6E6f7qWDT8U=
=lmbo
-----END PGP SIGNATURE-----

Re: Git versus Hg

[Tom Cooksey]

> What is still unclear to me is how well a shared git repository with
> push access for multiple parties is going to work. The mobile-linux
> repository on serenity had some kind of permission trouble before we
> added the group permission fixup in the post-update hook.

In Trolltech, we are currently "migrating" from perforce to git. At the
moment my work-flow is to use git-p4 script to pull in changes from
the central p4 repo. Then I use git locally with several different 
branches (one for each area I'm working on). When I'm happy with
something and want to push it into our main repo, I again use the
git-p4 script.

This kindof hybrid style of working suits me pretty well as I know I
can't mess anything up in the central repo with just git. :-) The git-p4
script integrates the change history etc. so it's like working nativly
with git. 

I've also tried to push things with git and found it's pretty tough to 
get right the first time you try.

I've noticed there are similar integration scripts for svn. Perhaps 
there could be a "central" svn repo, then individual developers can use 
git locally. You can still setup git remotes to cherry pick other people's 
commits, if you need that.


As an OpenEmbedded newbie, one more thing I would say is this:

The learning curve for OpenEmbedded is huge. The documentation
is rather sparce and I personally found trying to understand what's
going on very difficult (I'm also a python newbie which probably 
didn't help!). If you choose a well-known SCM system, it's one less 
thing new potential developers need to learn. They have enough to 
learn as it is.



Cheers,

Tom

PS: Personally, I'd never heard of Hg until reading threads on this list.

Re: Git versus Hg

[Paul Sokolovsky]

Hello,

On Wed, 12 Mar 2008 15:51:49 +0100
Tom Cooksey <thomas.cooksey@trolltech.com> wrote:

[]
> If you choose a well-known SCM system, it's one less 
> thing new potential developers need to learn. They have enough to 
> learn as it is.
> 
> Cheers,
> 
> Tom
> 
> PS: Personally, I'd never heard of Hg until reading threads on this
> list.

And you won't believe, but many people never heard about Perforce, even
though it has been alternative (commercial, plus OpenSource loyalty
program) to CVS for something like decade (cannot be exact, but 7
years ago it was there for sure). Many large entities still selected
CVS and spent money on "reduced development productivity and extra
maintenance costs" (forgive my corporate-speak), just because it was so
familiar.

[]


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

Re: Git versus Hg

[Tom Cooksey]

> > If you choose a well-known SCM system, it's one less 
> > thing new potential developers need to learn. They have enough to 
> > learn as it is.
> > 
> > Cheers,
> > 
> > Tom
> > 
> > PS: Personally, I'd never heard of Hg until reading threads on this
> > list.
> 
> And you won't believe, but many people never heard about Perforce, even
> though it has been alternative (commercial, plus OpenSource loyalty
> program) to CVS for something like decade (cannot be exact, but 7
> years ago it was there for sure). Many large entities still selected
> CVS and spent money on "reduced development productivity and extra
> maintenance costs" (forgive my corporate-speak), just because it was so
> familiar.

Yep, I was one of them. Never heard of perforce before starting at Trolltech. :-)

I think I have limited SCM knowledge. CVS, SVN, Git, Starteam (eeek) were 
the only ones I really knew about, until fairly recently.

Re: Git versus Hg

[Paul Sokolovsky]

Hello,

On Wed, 12 Mar 2008 10:08:26 -0400
"Cliff Brake" <cliff.brake@gmail.com> wrote:

> On Tue, Mar 11, 2008 at 7:53 PM, Philip Balister
> <philip@balister.org> wrote:
> > Given the only serious contenders for possible SCM's for OE appear
> > to be git or Hg, I am curious about the expertise level available
> > on this list.
> >
> >  Basically, let us know if you use git or Hg on a regular basis in
> > a two way workflow and consider yourself knowledgeable on sorting
> > out problems that crop up.
> 
> I use git regularly for kernel and u-boot development, and have
> managed to get a flow going with multiple public repositories where
> developers pull from public repositories.  This all works very well.
> I have not set up a shared public repository yet, but will give it a
> try to see how it works as I could use that capability that with a
> current project.
> 
> Mercurial looks very interesting and nice in many aspects, but I have
> not used it yet.  It seems to me one of the fundamental differences is
> the concept of cheap/easy local branches.  Mercurial is working on
> something like that
> (http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches), but
> it is obviously not central to its philosophy like git .  The idea of
> creating many local branches a normal port of your development
> workflow seems unique to git. As the gitmagic link below states, it
> makes it very easy to switch context to fix a bug, and then resume
> work on another feature.

Ok, so let's finally visualize how this unique feature would apply to
OE. So, we have set up all the BBPATH, build dir to reference to OE
working copy. Now, one magic spell, and OE working copy transmogrifies
into something else than it was before. What's next?

1. Suppose that we have thought that before, and prepared separate
build dir for this another local branch. Here, it's important to not
miss which build dir to use for which of workdir's phases of moon.
That's a bit harder that it would be with branches checked out into
separate workdirs, but careful people indeed can run many days before
making mistake. But all in all, "lightweight branching in OE" is not
that "lightweight" as just issuing SCM command.

2. Now suppose that we don't think that multiple builddirs is a must.
Then, we rm -rf tmp/ with each branch switch, or what? Btw, I wonder
how kernel people *actually* deal with that problem. Because only CS
freshman would buy into "very easy to switch context to fix a bug, and
then resume work on another feature." Real developers know, that fixes
are accompanied by testing.

3. Now let's think what happens if mistake was made per above (workdir
not switched, tmp dir not removed, ...) - we either already see errors
during build and end up with garbled builddir, or end up with builddir
garbled, but in silent manner. The latter is obvious good candidate
case for submitting in a week bugs that OE behaves.

4. And finally, what happens if we didn't think about all the above?
That's likely what will happen with newcomers and "mere users". They
may have no idea that building different OE branches may require
different builddirs. They may not know if given branch requires that,
or no. Ability to switch branches in-place would give them false
premise that it actually can be done easily. And give them good tool to
shoot themselves in feet.



What am I missing? Why it's not going to be like that, or why it's not
important? Let's think about that now, and not leave surprises (just
surprises for us, unpleasant surprises for our users) for later time.

[]

> Some more information on git branches:
> http://reddit.com/r/programming/info/69qe8/comments/c039eef
> http://www-cs-students.stanford.edu/~blynn/gitmagic/ch04.html
> http://mjtsai.com/blog/2007/07/15/subversion-to-git/
> http://www.dribin.org/dave/blog/archives/2007/12/30/why_mercurial/
> http://utsl.gen.nz/talks/git-svn/intro.html#howto-branch

Thanks for the links and mail, I believe that caused people unfamiliar
with hg to get to know it at least a bit, and led us to much more
grounded choice, than based on just personal preferences.

[]
> 
> Cliff
> 

[]

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

Re: Git versus Hg

[Koen Kooi]

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

Philip Balister schreef:
| Given the only serious contenders for possible SCM's for OE appear to be
| git or Hg, I am curious about the expertise level available on this list.

A big problem with git:

* it cannot import a flat OE repository (e.g a mtn checkout of .dev)
* it cannot import a OE repo with history (e.g with mtn2git)

Why? Git can't store empty dirs, and we use that in a few key places in
OE. Holger 'solved' that in mtn2git by putting in a lot .dummy files
into those dirs, but those will end up in your packages and rootfses.

regards,

Koen

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

iD8DBQFH2OytMkyGM64RGpERAtgeAJ9qYT/YrievJo72ymvysvcuQfnyyACgolqO
Y8sMKJ6WA5PjrAwl1j6Q0/w=
=VgCW
-----END PGP SIGNATURE-----

Re: Git versus Hg

[Paul Sokolovsky]

Hello,

On Thu, 13 Mar 2008 09:58:21 +0100
Koen Kooi <koen@dominion.kabel.utwente.nl> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Philip Balister schreef:
> | Given the only serious contenders for possible SCM's for OE appear
> to be | git or Hg, I am curious about the expertise level available
> on this list.
> 
> A big problem with git:
> 
> * it cannot import a flat OE repository (e.g a mtn checkout of .dev)
> * it cannot import a OE repo with history (e.g with mtn2git)
> 
> Why? Git can't store empty dirs, and we use that in a few key places
> in OE. Holger 'solved' that in mtn2git by putting in a lot .dummy
> files into those dirs, but those will end up in your packages and
> rootfses.

Heh, it seems that Git's spiritual ancestor, CVS, strikes back from
behind the facade of novelty features. That's good display that similar
design and implementation approaches lead to similar "features" for
users to work around. Well-well, I shutup, shutup.

> 
> regards,
> 
> Koen

[]


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

Re: Git versus Hg

[Esben Haabendal]

On Thu, Mar 13, 2008 at 9:58 AM, Koen Kooi <koen@dominion.kabel.utwente.nl>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Philip Balister schreef:
> | Given the only serious contenders for possible SCM's for OE appear to be
> | git or Hg, I am curious about the expertise level available on this
> list.
>
> A big problem with git:
>
> * it cannot import a flat OE repository (e.g a mtn checkout of .dev)
> * it cannot import a OE repo with history (e.g with mtn2git)
>
> Why? Git can't store empty dirs, and we use that in a few key places in
> OE. Holger 'solved' that in mtn2git by putting in a lot .dummy files
> into those dirs, but those will end up in your packages and rootfses.
>

There is a patch for handling empty directories in git.
http://kerneltrap.org/mailarchive/git/2007/7/18/252001
But it seems like the conclusion was tracking empty directories are not
necesarely such a good idea after all.

Other projects seems to have overcome it as well:
http://groups.google.com/group/rails-oceania/browse_thread/thread/2c8611dc93917952/e175f72310823547

Linus is all for adding tracking of empty directories, but is not working on
it himself.

I don't know if anybody is working on it, or if it really is of such vital
importance to us.
The alternative of adding a dummy file (fx. .gitignore) to those empty
directories that we do want to track, would of-course require that we have
these excluded when copying to fx. rootfs trees.

/Esben

Re: Git versus Hg

[Richard Purdie]

On Thu, 2008-03-13 at 09:58 +0100, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Philip Balister schreef:
> | Given the only serious contenders for possible SCM's for OE appear to be
> | git or Hg, I am curious about the expertise level available on this list.
> 
> A big problem with git:
> 
> * it cannot import a flat OE repository (e.g a mtn checkout of .dev)
> * it cannot import a OE repo with history (e.g with mtn2git)
> 
> Why? Git can't store empty dirs, and we use that in a few key places in
> OE. Holger 'solved' that in mtn2git by putting in a lot .dummy files
> into those dirs, but those will end up in your packages and rootfses.

Just for reference this is a problem already seen by people trying to
use OE metadata in things like svn. I've given this some through from
the svn PoV in the past and removing the files from the packages and
rootfses should just be a case of handling the files in do_unpack which
is what actually does the file copying.

Cheers,

Richard

Re: Git versus Hg

[pHilipp Zabel]

On Thu, Mar 13, 2008 at 9:58 AM, Koen Kooi
<koen@dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Philip Balister schreef:
>
> | Given the only serious contenders for possible SCM's for OE appear to be
>  | git or Hg, I am curious about the expertise level available on this list.
>
>  A big problem with git:
>
>  * it cannot import a flat OE repository (e.g a mtn checkout of .dev)
>  * it cannot import a OE repo with history (e.g with mtn2git)
>
>  Why? Git can't store empty dirs, and we use that in a few key places in
>  OE. Holger 'solved' that in mtn2git by putting in a lot .dummy files
>  into those dirs, but those will end up in your packages and rootfses.

Unrelated to the SCM discussion, do we need those empty directories at all?

$ find -type d -empty
./_MTN/tmp
./packages/dbus/dbus-python
./packages/xhost
./packages/gcc/gcc-4.1.0
./packages/xmodmap
./packages/netbase/netbase/if-up.d
./packages/netbase/netbase/if-pre-up.d
./packages/netbase/netbase/if-post-down.d
./packages/netbase/netbase/if-down.d
./packages/netbase/netbase/ghi270
./packages/xproto
./packages/xrandr
./packages/linux/linux-openmoko-devel
./packages/xrdb
./packages/sqlite/sqlite3-3.4.1
./packages/sqlite/sqlite3-3.3.17
./packages/kismet/kismet-2007-10-R1
./packages/xprop
./packages/tslib/tslib-1.0
./packages/xset
./packages/xfonts

Except for the netbase directories, they look like leftovers to me.

regards
Philipp

Re: Git versus Hg

[Richard Purdie]

On Thu, 2008-03-13 at 10:15 +0200, Paul Sokolovsky wrote:
> Ok, so let's finally visualize how this unique feature would apply to
> OE. So, we have set up all the BBPATH, build dir to reference to OE
> working copy. Now, one magic spell, and OE working copy transmogrifies
> into something else than it was before. What's next?
> 
> 1. Suppose that we have thought that before, and prepared separate
> build dir for this another local branch. Here, it's important to not
> miss which build dir to use for which of workdir's phases of moon.
> That's a bit harder that it would be with branches checked out into
> separate workdirs, but careful people indeed can run many days before
> making mistake. But all in all, "lightweight branching in OE" is not
> that "lightweight" as just issuing SCM command.

Agreed, using lightweight branches means you do have to be careful what
you're doing with them. The kind of useful usecase I envisage is where
some person says "can you commit foo?". In that case I can switch
whatever checkout I'm using to OE.dev, update it, commit foo and push
and then switch back to what I was doing. I might even merge it into a
temporary merge'd branch of whatever head is compatible with my workdir
so I can test it.

An OE checkout here appears to weigh in at ~222MB. What you're proposing
is that I should keep multiple copies of this around, just so I can do
multiple things at once. If I don't have the right checkout handy that
is 222MB of disk IO before I can do anything and 222MB of disk IO I then
have to remove.

Whilst harddisk space is cheap, its not that cheap and even my new
desktop which was custom spec'd for OE/poky work runs out frequently due
to the number of things I'm working on at once. When I'm on the laptop
the problem is a lot worse and thats with a laptop spec'd to cope with
OE.

> 2. Now suppose that we don't think that multiple builddirs is a must.
> Then, we rm -rf tmp/ with each branch switch, or what? Btw, I wonder
> how kernel people *actually* deal with that problem. Because only CS
> freshman would buy into "very easy to switch context to fix a bug, and
> then resume work on another feature." Real developers know, that fixes
> are accompanied by testing.

See above, I can merge it into my current work tree and test. Yes, this
assumes that my changes in the work tree don't influence the testing but
most kernel developers and most OE developers can usually manage to work
this out.

> 3. Now let's think what happens if mistake was made per above (workdir
> not switched, tmp dir not removed, ...) - we either already see errors
> during build and end up with garbled builddir, or end up with builddir
> garbled, but in silent manner. The latter is obvious good candidate
> case for submitting in a week bugs that OE behaves.

The nature of OE means you can garble a workdir in thousands of
different ways.

We are working on making rebuilds and recovery cheaper and detection of
corruption better. 

> 4. And finally, what happens if we didn't think about all the above?
> That's likely what will happen with newcomers and "mere users". They
> may have no idea that building different OE branches may require
> different builddirs. They may not know if given branch requires that,
> or no. Ability to switch branches in-place would give them false
> premise that it actually can be done easily. And give them good tool to
> shoot themselves in feet.

This is why we now have things like staging ABI versioning. The user
gets warned of the incompatibility. No its not perfect but some of us
are already trying to address this kind of problem which already exists
without the SCM consideration.

Cheers,

Richard

Re: Git versus Hg

[Marcin Juszkiewicz]

Dnia Thursday 13 of March 2008, pHilipp Zabel napisał:
> Unrelated to the SCM discussion, do we need those empty directories at
> all?

> ./packages/netbase/netbase/if-up.d
> ./packages/netbase/netbase/if-pre-up.d
> ./packages/netbase/netbase/if-post-down.d
> ./packages/netbase/netbase/if-down.d

Can be created by recipe.

> ./packages/netbase/netbase/ghi270

To be removed rather.

> Except for the netbase directories, they look like leftovers to me.

Leftovers or can be created in recipe.

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

                    Resistance Is Useless! (If < 1 ohm)

Re: Git versus Hg

[Richard Purdie]

On Thu, 2008-03-13 at 12:27 +0100, pHilipp Zabel wrote:
> Unrelated to the SCM discussion, do we need those empty directories at all?

I wondered this, probably not...

> ./packages/kismet/kismet-2007-10-R1

A missing patch I have locally, now committed, oops :)

> ./packages/xhost
> ./packages/xmodmap
> ./packages/xproto
> ./packages/xrandr
> ./packages/xrdb
> ./packages/xprop
> ./packages/xset
> ./packages/xfonts

Don't exist in OE.dev, try running "mtn list unknown".

> ./packages/dbus/dbus-python
> ./packages/linux/linux-openmoko-devel
> ./packages/gcc/gcc-4.1.0
> ./packages/tslib/tslib-1.0
> ./packages/sqlite/sqlite3-3.4.1
> ./packages/sqlite/sqlite3-3.3.17
> ./packages/netbase/netbase/ghi270

Removed as not needed.

> ./packages/netbase/netbase/if-up.d
> ./packages/netbase/netbase/if-pre-up.d
> ./packages/netbase/netbase/if-post-down.d
> ./packages/netbase/netbase/if-down.d

So these are the only remaining problem and changing the recipe slightly
can solve that.

In my previous mail I mentioned issues with .svn, just for clarity in
that case its not empty directories that cause problems but the .svn
directory itself being copied around by do_unpack. Both this and
the .dummy problem suggest we need a way of ignoring files in do_unpack
though.

Cheers,

Richard

Re: Git versus Hg

[Cliff Brake]

On Thu, Mar 13, 2008 at 4:15 AM, Paul Sokolovsky <pmiscml@gmail.com> wrote:
>  On Wed, 12 Mar 2008 10:08:26 -0400
>  "Cliff Brake" <cliff.brake@gmail.com> wrote:
>  > Mercurial looks very interesting and nice in many aspects, but I have
>  > not used it yet.  It seems to me one of the fundamental differences is
>  > the concept of cheap/easy local branches.  Mercurial is working on
>  > something like that
>  > (http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches), but
>  > it is obviously not central to its philosophy like git .  The idea of
>  > creating many local branches a normal port of your development
>  > workflow seems unique to git. As the gitmagic link below states, it
>  > makes it very easy to switch context to fix a bug, and then resume
>  > work on another feature.
>
>  Ok, so let's finally visualize how this unique feature would apply to
>  OE. So, we have set up all the BBPATH, build dir to reference to OE
>  working copy. Now, one magic spell, and OE working copy transmogrifies
>  into something else than it was before. What's next?
>
>  1. Suppose that we have thought that before, and prepared separate
>  build dir for this another local branch. Here, it's important to not
>  miss which build dir to use for which of workdir's phases of moon.
>  That's a bit harder that it would be with branches checked out into
>  separate workdirs, but careful people indeed can run many days before
>  making mistake. But all in all, "lightweight branching in OE" is not
>  that "lightweight" as just issuing SCM command.

I would use git branches for working on features at the tip of OE, and
branches are also very useful for keeping track of customizations at
several points in a source tree's history.  For example with kernel
work on one project, I have the following branches:

  2.6.23-rc4-rt1
  2.6.24-rt1
  cmx270
  cmx270_2.6.21
  cmx270_2.6.22
  cmx270_2.6.23
* cmx270_2.6.24
  cmx270_2.6.24-rc5
  cmx270_old
  cmx270_old2
  master
  svs_2.6.20
  svs_2.6.22
  svs_2.6.23-rc4-rt1
  svs_2.6.23-rc6
  svs_2.6.23-rc6_backup
  svs_2.6.23-rt1
  svs_2.6.24
  svs_2.6.24-rc5
  svs_2.6.24-rc5-rt1
  svs_2.6.24-rc5-rt1_old
  svs_2.6.24-rc8
  svs_2.6.24-rt1
  svs_old
  v2.6.20_test

Git branches allow me to keep the old branch for reference if I ever
need to go back to it, and easily move it forward to a new point in
the kernel development.  I suppose the same thing can be done with
tags.  I really don't like the idea of creating separate
repositories/workspaces for different branches.  But, with different
tools, you just develop a different workflow.  With monotone, I use
overlays ...

>  2. Now suppose that we don't think that multiple builddirs is a must.
>  Then, we rm -rf tmp/ with each branch switch, or what? Btw, I wonder
>  how kernel people *actually* deal with that problem. Because only CS
>  freshman would buy into "very easy to switch context to fix a bug, and
>  then resume work on another feature." Real developers know, that fixes
>  are accompanied by testing.

This is a valid concern, but again the assumption is that if you are
using git branches in OE, it is probably near the tip of the OE tree.
Bitbake -c clean works well.  If you move back in time, then cleaning
tmp or switching tmp is obviously advised.

BTW, the kernel build system _can_ handle switching branches very well
without "make clean".  I routinely switch branches in a workspace and
type make without cleaning and it just works.  Try it sometime, you
may like it :-)  I may be a CS freshman, but that is irrelevant
because it does work very well and many people use it.

Interesting discussion and good points.  I guess the bottom line is
there are different tools, and different people will have different
preferences because people work differently, which is fine.  I'm ok
with either choice (not that it really matters), and I'm not opposed
to learning something new -- matter of fact, I would love a good
excuse to learn hg.  I do think it is difficult for anyone to make
informed decisions about tools of this complexity without having used
it to do real work.  That is where most of us stand with hg.

I still maintain that that tools do impact developer workflow, and
this should be a serious consideration when selecting tools.  What is
the workflow that will maximize the productivity and output of the OE
community?  The tool selection should follow.

Cliff

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

Re: Git versus Hg

[Cliff Brake]

On Wed, Mar 12, 2008 at 10:28 AM, Koen Kooi
<koen@dominion.kabel.utwente.nl> wrote:
>  Cliff Brake schreef:
>
>
>  | Mercurial looks very interesting and nice in many aspects, but I have
>  | not used it yet.  It seems to me one of the fundamental differences is
>  | the concept of cheap/easy local branches.  Mercurial is working on
>  | something like that
>  | (http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches), but
>  | it is obviously not central to its philosophy like git .  The idea of
>  | creating many local branches a normal port of your development
>  | workflow seems unique to git.  As the gitmagic link below states, it
>  | makes it very easy to switch context to fix a bug, and then resume
>  | work on another feature.  This is a lot more than just "being good at
>  | generating patches"; it is a change in the way we work.
>
>  I can see how that's a good thing for what I call "traditional
>  application development" where a bunch of source files get compiled into
>  a single application (kernel, u-boot, xserver etc) where working on
>  multiple things at once doesn't work, since it makes building and
>  testing a nightmare. Easy branching solves that.
>
>  But OE isn't like that, it's a collection of build descriptions, which
>  makes it possible to be working on a 1000 different recipes at the same
>  time. This also is one of the reasons why mtn is so slow for us: lots of
>  files with a shortlived life spam and ±30 commits per day.

Good point.  BTW, I do appreciate your perspective and contribution to
OE.  At times like this, this appreciation may not be very obvious,
but you have done a great deal to keep the project moving and the
infrastructure running.  Many thanks!

Cliff

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

Re: Git versus Hg

[Koen Kooi]

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

Cliff Brake schreef:
| matter of fact, I would love a good
| excuse to learn hg.

Hg has virtually the same UI as mtn, so "learning" is too big a word for
it. "Stop my fingers from typing mtn" would be a better description :)

regards,

Koen

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

iD8DBQFH2Ug9MkyGM64RGpERAp2/AJ40JGyVn3WA8j1HTAsaD/AHEYntrQCfU8QP
+bCNtz4VNbbsSbWJYkga5xU=
=dmLn
-----END PGP SIGNATURE-----

Re: Git versus Hg

[Koen Kooi]

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

Cliff Brake schreef:

| I still maintain that that tools do impact developer workflow, and
| this should be a serious consideration when selecting tools.  What is
| the workflow that will maximize the productivity and output of the OE
| community?  The tool selection should follow.

Having been through the bk->mtn switchover and the re-evaluation I
noticed that people who said "I will start contributing (much more) to
OE if you weren't using bitkeeper" didn't actually start contributing
*at all*, so I'm extremely sceptical of the promised influx of a
gazillion ISVs, OEMs, ODMs and users with a switch to hg/git/vss.

All I can see is that the people taking care of the OE infrastructure
(Mickey and me) will have to allocate some weeks to do a good
changeover[1], and we both aren't known for our copious amounts of spare
time that would be needed.

regards,

Koen

[1] As it is, we were(are?) beginning the move of large parts of the
existing infrastructure to a new machine, but that's put on hold[2] due
to this discussion.
[2] Yes, that's why you haven't seen any commits mails lately.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH2UsrMkyGM64RGpERAlvcAJ92SgGXGs8amaDIN1ef+JAlxXtqmgCgqTkF
4vrvx1JEyVXseQRAp7D2w1o=
=594a
-----END PGP SIGNATURE-----

Re: Git versus Hg

[Paul Sokolovsky]

Hello,

On Thu, 13 Mar 2008 11:28:10 +0000
Richard Purdie <rpurdie@rpsys.net> wrote:

> On Thu, 2008-03-13 at 10:15 +0200, Paul Sokolovsky wrote:
> > Ok, so let's finally visualize how this unique feature would apply
> > to OE. So, we have set up all the BBPATH, build dir to reference to
> > OE working copy. Now, one magic spell, and OE working copy
> > transmogrifies into something else than it was before. What's next?
> > 
> > 1. Suppose that we have thought that before, and prepared separate
> > build dir for this another local branch. Here, it's important to not
> > miss which build dir to use for which of workdir's phases of moon.
> > That's a bit harder that it would be with branches checked out into
> > separate workdirs, but careful people indeed can run many days
> > before making mistake. But all in all, "lightweight branching in
> > OE" is not that "lightweight" as just issuing SCM command.
> 
> Agreed, using lightweight branches means you do have to be careful
> what you're doing with them. 

Sounds good. What I'm failing to grasp is where thresholds and tipping
points of this logic. Why feature1 which potentially risky but was
bound and restricted for specific usecase considered harmful, while
feature2 with similar characteristics don't raise much concern? As
usual for out-of-band questions, it's mostly rhetoric one.

> The kind of useful usecase I envisage is
> where some person says "can you commit foo?". In that case I can
> switch whatever checkout I'm using to OE.dev, update it, commit foo
> and push and then switch back to what I was doing. I might even merge
> it into a temporary merge'd branch of whatever head is compatible
> with my workdir so I can test it.

Ok.

> An OE checkout here appears to weigh in at ~222MB. 

Aha, so I'm getting anachronic with this stuff - I kinda worn pink
glasses that our codebase still/is some tens of megabytes. Well, 200Mb
add weight to lightweight branches priority.

> What you're
> proposing is that I should keep multiple copies of this around, just
> so I can do multiple things at once. If I don't have the right
> checkout handy that is 222MB of disk IO before I can do anything and
> 222MB of disk IO I then have to remove.
> 
> Whilst harddisk space is cheap, its not that cheap and even my new
> desktop which was custom spec'd for OE/poky work runs out frequently
> due to the number of things I'm working on at once. When I'm on the
> laptop the problem is a lot worse and thats with a laptop spec'd to
> cope with OE.

I'm not that much of proposing to have multiple copies around, than
point that it's the most obvious way to deal with that, which people
have been using all the time. You rejected SVN parallel, but make me
come back to it in more explicit example:

Do you, or someone else of O-Hand folks have following setup:

-------
svn co http://svn.o-hand.com/repos/poky/trunk
then:
svn switch http://svn.o-hand.com/repos/poky/branches/blinky
or
svn switch http://svn.o-hand.com/repos/poky/branches/clyde
...
then again
svn switch http://svn.o-hand.com/repos/poky/trunk
-------

vs
-------
svn co http://svn.o-hand.com/repos/poky/trunk
# Yes, all branches - customers may use any, so you probably want all
# branches easily accessible, right?
svn co http://svn.o-hand.com/repos/poky/branches
-------

The 1st *is* the same in-place branch switching paradigm as git
(except that it of course won't blow your uncommitted changes, etc.)
Would you at least consider such workflow with SVN?

So, it the case that we need lightweight in-place branches and select
git, or select git, and use lightweight branches just becasue git
postulates (forces by authority?) such workflow?


And finally, there's still other alternative - for developers, to
moderate their appetite, choosing only some healthy food subset, giving
up on delicatessen which are so tasty for them, but can give stomach
problems to users. That's the hg alternative. And developers won't
necessary lose - they will skip the need to learn too complex and
peculiar stuff (As was pointed several times by Koen and me, one
doesn't really need to "learn" hg, at least to start working in
similar manner to what we have now, and more advanced use should come
in naturally either).


So, if you considered all these (and those) alternatives, compromises,
and criteria, and think that what git offers worth more complicated
learning and use curve for everyone in OE community, then that must be
it. It's different from assuming that git will win anyway, and not
caring about what entailments such choice will bring.

> 
> > 2. Now suppose that we don't think that multiple builddirs is a
> > must. Then, we rm -rf tmp/ with each branch switch, or what? Btw, I
> > wonder how kernel people *actually* deal with that problem. Because
> > only CS freshman would buy into "very easy to switch context to fix
> > a bug, and then resume work on another feature." Real developers
> > know, that fixes are accompanied by testing.
> 
> See above, I can merge it into my current work tree and test. Yes,
> this assumes that my changes in the work tree don't influence the
> testing but most kernel developers and most OE developers can usually
> manage to work this out.
> 
> > 3. Now let's think what happens if mistake was made per above
> > (workdir not switched, tmp dir not removed, ...) - we either
> > already see errors during build and end up with garbled builddir,
> > or end up with builddir garbled, but in silent manner. The latter
> > is obvious good candidate case for submitting in a week bugs that
> > OE behaves.
> 
> The nature of OE means you can garble a workdir in thousands of
> different ways.
> 
> We are working on making rebuilds and recovery cheaper and detection
> of corruption better. 

That's nice.

> 
> > 4. And finally, what happens if we didn't think about all the above?
> > That's likely what will happen with newcomers and "mere users". They
> > may have no idea that building different OE branches may require
> > different builddirs. They may not know if given branch requires
> > that, or no. Ability to switch branches in-place would give them
> > false premise that it actually can be done easily. And give them
> > good tool to shoot themselves in feet.
> 
> This is why we now have things like staging ABI versioning. The user
> gets warned of the incompatibility. No its not perfect but some of us
> are already trying to address this kind of problem which already
> exists without the SCM consideration.

I'm glad that we're moving in that direction. That kinda shows that
we're not ready for that lightweight branches fully, but I'm glad
people are ready to make required changes fast, as empty dirs issue
shows. I just hope we're moving in that direction in consistent way. 

In that regard, do you remember myself once proposing to make bitbake
cache files to contain cache version suffix, so concurrent bitbake
version can be used? You rejected that idea on the basis that
concurrent bitbake version usage shouldn't be supported at all. I hope
we see evolution in treating such cases. Not that the specific issue is
relevant now - we're long out of 1.6 vs 1.8 move, but one day there may
be 2.0, and it may become important again.

> 
> Cheers,
> 
> Richard

[]

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

Re: Git versus Hg

[Paul Sokolovsky]

Hello,

On Thu, 13 Mar 2008 10:26:00 -0400
"Cliff Brake" <cliff.brake@gmail.com> wrote:

> On Thu, Mar 13, 2008 at 4:15 AM, Paul Sokolovsky <pmiscml@gmail.com>
> wrote:
> >  On Wed, 12 Mar 2008 10:08:26 -0400
> >  "Cliff Brake" <cliff.brake@gmail.com> wrote:
> >  > Mercurial looks very interesting and nice in many aspects, but I
> >  > have not used it yet.  It seems to me one of the fundamental
> >  > differences is the concept of cheap/easy local branches.
> >  > Mercurial is working on something like that
> >  > (http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches),
> >  > but it is obviously not central to its philosophy like git .
> >  > The idea of creating many local branches a normal port of your
> >  > development workflow seems unique to git. As the gitmagic link
> >  > below states, it makes it very easy to switch context to fix a
> >  > bug, and then resume work on another feature.
> >
> >  Ok, so let's finally visualize how this unique feature would apply
> > to OE. So, we have set up all the BBPATH, build dir to reference to
> > OE working copy. Now, one magic spell, and OE working copy
> > transmogrifies into something else than it was before. What's next?
> >
> >  1. Suppose that we have thought that before, and prepared separate
> >  build dir for this another local branch. Here, it's important to
> > not miss which build dir to use for which of workdir's phases of
> > moon. That's a bit harder that it would be with branches checked
> > out into separate workdirs, but careful people indeed can run many
> > days before making mistake. But all in all, "lightweight branching
> > in OE" is not that "lightweight" as just issuing SCM command.
> 
> I would use git branches for working on features at the tip of OE, and
> branches are also very useful for keeping track of customizations at
> several points in a source tree's history.  For example with kernel
> work on one project, I have the following branches:
> 
>   2.6.23-rc4-rt1
>   2.6.24-rt1
[]

List is long, I'm glad it's ok for you keep track on so many things.

> 
> Git branches allow me to keep the old branch for reference if I ever
> need to go back to it, and easily move it forward to a new point in
> the kernel development.  I suppose the same thing can be done with
> tags.  I really don't like the idea of creating separate
> repositories/workspaces for different branches.  But, with different
> tools, you just develop a different workflow.  With monotone, I use
> overlays ...
> 
> >  2. Now suppose that we don't think that multiple builddirs is a
> > must. Then, we rm -rf tmp/ with each branch switch, or what? Btw, I
> > wonder how kernel people *actually* deal with that problem. Because
> > only CS freshman would buy into "very easy to switch context to fix
> > a bug, and then resume work on another feature." Real developers
> > know, that fixes are accompanied by testing.
> 
> This is a valid concern, but again the assumption is that if you are
> using git branches in OE, it is probably near the tip of the OE tree.

Ok, let's record in our minds this assumption, and be prepared to add
it do docs/howtos/best practices, and ready to answer users' concerns
regarding that.

> Bitbake -c clean works well.  If you move back in time, then cleaning
> tmp or switching tmp is obviously advised.
> 
> BTW, the kernel build system _can_ handle switching branches very well
> without "make clean".  I routinely switch branches in a workspace and
> type make without cleaning and it just works.  Try it sometime, you
> may like it :-)  I may be a CS freshman, but that is irrelevant
> because it does work very well and many people use it.

I obviously didn't mean you, referring to some authors of git "marketing
materials" who admit to having git as their first SCM, and not much
experience with other systems at all (like gitmagic author admits
explicitly for example).

And I'm glad that kernel build system handles that well - I assume it
has special support for such usage. That reminds that "repo control"
tool is actually only part of complete SCM picture, it includes
integration with build system, test system, issue tracking, etc. And OE
may not be well suited for that yet, and we should be prepared to make
changes towards that. That's another inference we can make, worthy
keeping in mind.

> 
> Interesting discussion and good points.  I guess the bottom line is
> there are different tools, and different people will have different
> preferences because people work differently, which is fine.  I'm ok
> with either choice (not that it really matters), and I'm not opposed
> to learning something new -- matter of fact, I would love a good
> excuse to learn hg.  I do think it is difficult for anyone to make
> informed decisions about tools of this complexity without having used
> it to do real work.  That is where most of us stand with hg.

I'm also ok with either tool, but I'm very much would like to have
internal confidence that we selected the tool based on weighting
different criteria and selecting best compromise based on them
(because it's going to be compromise, not the sole winner). And I also
let me to maintain belief that the more OE developers will participate
in this discussion, looking at the matter from different angles, and
getting similar confidence, the better.

> 
> I still maintain that that tools do impact developer workflow, and
> this should be a serious consideration when selecting tools.  What is
> the workflow that will maximize the productivity and output of the OE
> community?  The tool selection should follow.

I personally try to speak and advocate from a point of view of a
newcomer and hobbyist, who want to just add some software or device
support to OE, and thus would want to learn as little as possible on
the global scale (they don't know git or hg, that's it, which one
easier to use and learn for them). And I do so because other developers
IMHO don't look from that point of view too often, and yet that's
important user group to OE, without them we simply won't grow well
enough.

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



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

Re: Git versus Hg

[Tom Rini]

On Thu, Mar 13, 2008 at 04:41:32PM +0100, Koen Kooi wrote:
> Cliff Brake schreef:
> 
> | I still maintain that that tools do impact developer workflow, and
> | this should be a serious consideration when selecting tools.  What is
> | the workflow that will maximize the productivity and output of the OE
> | community?  The tool selection should follow.
> 
> Having been through the bk->mtn switchover and the re-evaluation I
> noticed that people who said "I will start contributing (much more) to
> OE if you weren't using bitkeeper" didn't actually start contributing
> *at all*, so I'm extremely sceptical of the promised influx of a
> gazillion ISVs, OEMs, ODMs and users with a switch to hg/git/vss.

As someone who (a) doesn't use / know mtn and (b) should submit more, or
at least quicker, our changes, I can say you're right here.  I've been
quite happy to grab current, whip out quilt, patch, file bugzilla &
attach.  Now, if OE switches to git, I might make drop quilt in favor of
git patch (since I still need to get better git-fu under my belt), and
probably the same with hg.  But it won't impact how much / often I
contribute at all.

-- 
Tom Rini

Re: Git versus Hg

[Richard Purdie]

On Thu, 2008-03-13 at 21:00 +0200, Paul Sokolovsky wrote:
> Sounds good. What I'm failing to grasp is where thresholds and tipping
> points of this logic. Why feature1 which potentially risky but was
> bound and restricted for specific usecase considered harmful, while
> feature2 with similar characteristics don't raise much concern? As
> usual for out-of-band questions, it's mostly rhetoric one.

I don't 100% follow, you mean when new features should be put on a
branch and when they can be directly committed?

> > An OE checkout here appears to weigh in at ~222MB. 
> 
> Aha, so I'm getting anachronic with this stuff - I kinda worn pink
> glasses that our codebase still/is some tens of megabytes. Well, 200Mb
> add weight to lightweight branches priority.

Right :)

> I'm not that much of proposing to have multiple copies around, than
> point that it's the most obvious way to deal with that, which people
> have been using all the time. You rejected SVN parallel, but make me
> come back to it in more explicit example:
> 
> Do you, or someone else of O-Hand folks have following setup:
> 
> -------
> svn co http://svn.o-hand.com/repos/poky/trunk
> then:
> svn switch http://svn.o-hand.com/repos/poky/branches/blinky
> or
> svn switch http://svn.o-hand.com/repos/poky/branches/clyde
> ...
> then again
> svn switch http://svn.o-hand.com/repos/poky/trunk
> -------
> 
> vs
> -------
> svn co http://svn.o-hand.com/repos/poky/trunk
> # Yes, all branches - customers may use any, so you probably want all
> # branches easily accessible, right?
> svn co http://svn.o-hand.com/repos/poky/branches
> -------

I actually have a full checkout and some symlinks which are kind of my
"svn switch" :).

> The 1st *is* the same in-place branch switching paradigm as git
> (except that it of course won't blow your uncommitted changes, etc.)
> Would you at least consider such workflow with SVN?

I think you'd find "svn switch" explodes fairly easily since its not
really designed to be used like that. Ignoring that, the IO (disk and
net) involved in svn switch is very heavy and it takes a comparative age
to run.

> So, it the case that we need lightweight in-place branches and select
> git, or select git, and use lightweight branches just becasue git
> postulates (forces by authority?) such workflow?

I use light weight branches in other projects (kernel work) and would
love to be able to use them for OE. git doesn't force that way of
working and you can still have multiple checkouts, just not many people
actually do that. Why? Because its actually a really useful feature :).

> And finally, there's still other alternative - for developers, to
> moderate their appetite, choosing only some healthy food subset, giving
> up on delicatessen which are so tasty for them, but can give stomach
> problems to users. That's the hg alternative. And developers won't
> necessary lose - they will skip the need to learn too complex and
> peculiar stuff (As was pointed several times by Koen and me, one
> doesn't really need to "learn" hg, at least to start working in
> similar manner to what we have now, and more advanced use should come
> in naturally either).
> 
> So, if you considered all these (and those) alternatives, compromises,
> and criteria, and think that what git offers worth more complicated
> learning and use curve for everyone in OE community, then that must be
> it. It's different from assuming that git will win anyway, and not
> caring about what entailments such choice will bring.

I don't deny the git UI is horrible. I've just said I consider git's
benefits in branching and the possible advantages an SCM in widespread
use has enough to outweight the UI.

> > This is why we now have things like staging ABI versioning. The user
> > gets warned of the incompatibility. No its not perfect but some of us
> > are already trying to address this kind of problem which already
> > exists without the SCM consideration.
> 
> I'm glad that we're moving in that direction. That kinda shows that
> we're not ready for that lightweight branches fully, but I'm glad
> people are ready to make required changes fast, as empty dirs issue
> shows. I just hope we're moving in that direction in consistent way. 
>
> In that regard, do you remember myself once proposing to make bitbake
> cache files to contain cache version suffix, so concurrent bitbake
> version can be used? You rejected that idea on the basis that
> concurrent bitbake version usage shouldn't be supported at all. I hope
> we see evolution in treating such cases. Not that the specific issue is
> relevant now - we're long out of 1.6 vs 1.8 move, but one day there may
> be 2.0, and it may become important again.

There will be a 2.0 someday if I have anything to do with it :)

On the subject of cache versioning, you would never want to run two
bitbakes on the same work directory at the same time. The cache file
acted as a kind of lock file against that although with the things in
the path to the cache file we have now, that doesn't work as well as it
once did.

If you switch between two bitbake versions, a cache rebuild isn't likely
to be too problematic or unreasonable though and that is the only real
result.

Just is case you don't realise, all recent versions of bitbake embed a
version number in the cache and will ignore it and rebuild if that
version isn't one they understand. This is part of the ongoing usability
drive I'm doing my best to push.

Cheers,

Richard

Re: Git versus Hg

[Koen Kooi]

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

Philip Balister schreef:
| Given the only serious contenders for possible SCM's for OE appear to be
| git or Hg, I am curious about the expertise level available on this list.
|
| Basically, let us know if you use git or Hg on a regular basis in a two
| way workflow and consider yourself knowledgeable on sorting out problems
| that crop up.

Hg can support git style local branches:
http://www.selenic.com/mercurial/wiki/index.cgi/LocalbranchExtension

regards,

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

iD8DBQFH2tWEMkyGM64RGpERAgJaAJ9Y4DyCcyDvKVBYVkVWS8RGFoIFLQCgh2nB
/ZNlKbbs2r+hkpctgQSnR5I=
=9cPZ
-----END PGP SIGNATURE-----