[alsa-devel] HG branches
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
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.
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.
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
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.
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
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.
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.
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
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.
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
participants (4)
-
Jaroslav Kysela -
Rene Herman -
Seth Forshee -
Takashi Iwai