HG branches

HG branches

[Takashi Iwai]

Hi,

how about creating branches for HG trees for some stable trees?  This
will make the maintenance much easier.

What I have in my mind are branches for:

- Kernel stable tree (2.6.xx.y)
- Kernel head tree for push
- ALSA stable releases

We'd need to define a naming rule if we have branches.  So far, v*.*.*
tag is used for ALSA versions, and it can be used for the branch, too.
But having the same name between the tag and the branch may be
confusing.  We can name the branch as "v1.0.16.x" or "v1.0.16-branch",
for example.

Also, for the kernel version to track, we'd need a different prefix,
too, such as "kernel-2.6.25".

The workflow with branches is pretty simple.

	% hg branch
	default
	% hg up -rv1.0.16
	% hg branch v1.0.16-branch
	% some patch work
	% hg commit
	% hg branches
	v1.0.16-branch	5828:71ddf13b7a2e
	default		5829:950e43bff743

The resultant multiple heads can be pushed via "push -f".


Takashi

Re: HG branches

[Jaroslav Kysela]

On Tue, 5 Feb 2008, Takashi Iwai wrote:

> Hi,
> 
> how about creating branches for HG trees for some stable trees?  This
> will make the maintenance much easier.

I agree.

> What I have in my mind are branches for:
> 
> - Kernel stable tree (2.6.xx.y)
> - Kernel head tree for push
> - ALSA stable releases
> 
> We'd need to define a naming rule if we have branches.  So far, v*.*.*
> tag is used for ALSA versions, and it can be used for the branch, too.
> But having the same name between the tag and the branch may be
> confusing.  We can name the branch as "v1.0.16.x" or "v1.0.16-branch",
> for example.

I would like to add word branch to all branches. Just for sure.

> Also, for the kernel version to track, we'd need a different prefix,
> too, such as "kernel-2.6.25".

Or "kernel-2.6.25-branch".

> The workflow with branches is pretty simple.
> 
> 	% hg branch
> 	default
> 	% hg up -rv1.0.16
> 	% hg branch v1.0.16-branch
> 	% some patch work
> 	% hg commit
> 	% hg branches
> 	v1.0.16-branch	5828:71ddf13b7a2e
> 	default		5829:950e43bff743
> 
> The resultant multiple heads can be pushed via "push -f".

You can also change back to default (main) branch with:

	hg up -C default

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: HG branches

[Jaroslav Kysela]

On Wed, 6 Feb 2008, Jaroslav Kysela wrote:

> On Tue, 5 Feb 2008, Takashi Iwai wrote:
> 
> > Hi,
> > 
> > how about creating branches for HG trees for some stable trees?  This
> > will make the maintenance much easier.
> 
> I agree.

BTW: Does anyone know if it's possible to just pick a patch from a HG 
branch to another? STG (Stacked GIT) has nice 'stg pick <branch>@<patch>' 
command for this.

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: HG branches

[Takashi Iwai]

At Wed, 6 Feb 2008 15:06:44 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Wed, 6 Feb 2008, Jaroslav Kysela wrote:
> 
> > On Tue, 5 Feb 2008, Takashi Iwai wrote:
> > 
> > > Hi,
> > > 
> > > how about creating branches for HG trees for some stable trees?  This
> > > will make the maintenance much easier.
> > 
> > I agree.
> 
> BTW: Does anyone know if it's possible to just pick a patch from a HG 
> branch to another? STG (Stacked GIT) has nice 'stg pick <branch>@<patch>' 
> command for this.

I don't know whether HG has such a command, but it's easy via a
combination of "hg export" and "hg import".


Takashi

Re: HG branches

[Rene Herman]

On 06-02-08 15:06, Jaroslav Kysela wrote:

> BTW: Does anyone know if it's possible to just pick a patch from a HG 
> branch to another? STG (Stacked GIT) has nice 'stg pick <branch>@<patch>'
> command for this.

Not me, but thought I'd take the opportunity to ask if switching to git is 
(still) an absolute no. As far as I can see, hg has mostly downsides, with 
needing a conduit between it and upstream for example that I saw Linus 
complain about recently.

I'm used to git by now, and every time I try do something inside ALSA I just 
keep on typing the wrong commands to hg, needing the manpage, not being 
certain that I'm not fucking up my local tree...

I can definitely say that hg is not being instrumental in making me more of 
a contributor. When I _do_ do something I tend to just work against the 
kernel inside git and then only in the end apply the result to the current 
hg just to see if it will.

I believe the git submodule stuff would also nicely allow all of ALSA to be 
one giant repo basically, with kernel, lib, ..., as submodules.

Rene.

Re: HG branches

[Seth Forshee]

On Wed, Feb 06, 2008 at 03:06:44PM +0100, Jaroslav Kysela wrote:
> BTW: Does anyone know if it's possible to just pick a patch from a HG 
> branch to another? STG (Stacked GIT) has nice 'stg pick <branch>@<patch>' 
> command for this.

  hg update -C dest-branch
  hg transplant -b source-branch revision

But I must say that using branches in hg is rather painful.  We tried
it for a while at my workplace and switched to using cloned repos for
branches (mostly).  We had several instances of bad things happening
because of the way hg handled branches, and when those things got
pushed it was often very difficult to get the repo back to a decent
state.  In my opinion git handles branches much better than hg does.

Cheers,
Seth

Re: HG branches

[Jaroslav Kysela]

On Wed, 6 Feb 2008, Seth Forshee wrote:

> On Wed, Feb 06, 2008 at 03:06:44PM +0100, Jaroslav Kysela wrote:
> > BTW: Does anyone know if it's possible to just pick a patch from a HG 
> > branch to another? STG (Stacked GIT) has nice 'stg pick <branch>@<patch>' 
> > command for this.
> 
>   hg update -C dest-branch
>   hg transplant -b source-branch revision
> 
> But I must say that using branches in hg is rather painful.  We tried
> it for a while at my workplace and switched to using cloned repos for
> branches (mostly).  We had several instances of bad things happening
> because of the way hg handled branches, and when those things got
> pushed it was often very difficult to get the repo back to a decent
> state.  In my opinion git handles branches much better than hg does.

Thanks for these notes.

					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: HG branches

[Takashi Iwai]

At Wed, 6 Feb 2008 19:59:24 -0600,
Seth Forshee wrote:
> 
> On Wed, Feb 06, 2008 at 03:06:44PM +0100, Jaroslav Kysela wrote:
> > BTW: Does anyone know if it's possible to just pick a patch from a HG 
> > branch to another? STG (Stacked GIT) has nice 'stg pick <branch>@<patch>' 
> > command for this.
> 
>   hg update -C dest-branch
>   hg transplant -b source-branch revision
> 
> But I must say that using branches in hg is rather painful.  We tried
> it for a while at my workplace and switched to using cloned repos for
> branches (mostly).  We had several instances of bad things happening
> because of the way hg handled branches, and when those things got
> pushed it was often very difficult to get the repo back to a decent
> state.  In my opinion git handles branches much better than hg does.

Fair enough.

I prpoposed HG branch because I have no way to create new repos by
myself.  The branch doesn't require a repo creation.  But, an
individual repo is of course a safer and well-checked solution.

Probably it's same to git, too, although git seems to be able to
handle branches better (and easier to repair trees).


Takashi

Re: HG branches

[Takashi Iwai]

At Wed, 06 Feb 2008 21:06:57 +0100,
Rene Herman wrote:
> 
> On 06-02-08 15:06, Jaroslav Kysela wrote:
> 
> > BTW: Does anyone know if it's possible to just pick a patch from a HG 
> > branch to another? STG (Stacked GIT) has nice 'stg pick <branch>@<patch>'
> > command for this.
> 
> Not me, but thought I'd take the opportunity to ask if switching to git is 
> (still) an absolute no. As far as I can see, hg has mostly downsides, with 
> needing a conduit between it and upstream for example that I saw Linus 
> complain about recently.

Well, this isn't about HG but the mechanism that alsa.git tree is
generated.  The same would happen if you do automatic-commitment
between different trees.

It would be same even if you use git, as long as you have a different
tree structure like the current alsa-kernel tree vs linux kernel
tree.

> I'm used to git by now, and every time I try do something inside ALSA I just 
> keep on typing the wrong commands to hg, needing the manpage, not being 
> certain that I'm not fucking up my local tree...
> 
> I can definitely say that hg is not being instrumental in making me more of 
> a contributor. When I _do_ do something I tend to just work against the 
> kernel inside git and then only in the end apply the result to the current 
> hg just to see if it will.
> 
> I believe the git submodule stuff would also nicely allow all of ALSA to be 
> one giant repo basically, with kernel, lib, ..., as submodules.

Just out of curiosity, what could be a merit of submodules in the case
of ALSA?


Takashi

GIT submodules

[Rene Herman]

On 07-02-08 12:37, Takashi Iwai wrote:

>> I believe the git submodule stuff would also nicely allow all of ALSA to be 
>> one giant repo basically, with kernel, lib, ..., as submodules.
> 
> Just out of curiosity, what could be a merit of submodules in the case
> of ALSA?

Given that they're used for larger projects, I can't say I've used them but 
I read about them when Linus mentioned them in the context of KDE maybe 
switching:

http://lwn.net/Articles/246381/

Basically, submodules are the  actual git repositories with one organizing 
superproject. This seems to be a fairly nice description of the submodule 
support:

http://www.ishlif.org/blog/linux/git-submodules/

What they provide is stitching the parts together nicely into one coherent 
release. In this case, you'd have alsa-driver, alsa-lib, alsa-utils and so 
on repos, and an "alsa-project" superproject tying them together, where you 
could do checkouts of a complete coherent release off all the modules for 
example.

As said, I haven't actually used them, so I've added the git list (*) to see 
if anyone has something to add, correct or explain (please do!). Submodules 
seem to be intended exactly for the kind of setup that ALSA is using with 
the many semi-independent parts...

(*) git-devel: alsa-devel is moderated for non-subscribers but you'll be 
whitelisted after landing in the queue once if you're not a subscriber

Rene.

GIT submodules

[Rene Herman]

On 07-02-08 12:37, Takashi Iwai wrote:

(sorry, that's not git-devel@, but simply git@)

>> I believe the git submodule stuff would also nicely allow all of ALSA to be 
>> one giant repo basically, with kernel, lib, ..., as submodules.
> 
> Just out of curiosity, what could be a merit of submodules in the case
> of ALSA?

Given that they're used for larger projects, I can't say I've used them but
I read about them when Linus mentioned them in the context of KDE maybe
switching:

http://lwn.net/Articles/246381/

Basically, submodules are the  actual git repositories with one organizing
superproject. This seems to be a fairly nice description of the submodule
support:

http://www.ishlif.org/blog/linux/git-submodules/

What they provide is stitching the parts together nicely into one coherent
release. In this case, you'd have alsa-driver, alsa-lib, alsa-utils and so
on repos, and an "alsa-project" superproject tying them together, where you
could do checkouts of a complete coherent release off all the modules for
example.

As said, I haven't actually used them, so I've added the git list (*) to see
if anyone has something to add, correct or explain (please do!). Submodules
seem to be intended exactly for the kind of setup that ALSA is using with
the many semi-independent parts...

(*) git list: alsa-devel is moderated for non-subscribers but you'll be
whitelisted after landing in the queue once if you're not a subscriber

Rene.