Hi Andreas K., Just a couple of questions: * Does Sebastian Geerken have commit permission in our hg repo? (if not, please enable him). * Can corvid make another repo in the same server? (e.g. for the port to fltk-1.3) TIA -- Cheers Jorge.-
On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote:
* Can corvid make another repo in the same server? (e.g. for the port to fltk-1.3)
Isn't it better to just make an other branch in the same repo? Can't everybody with commit access do that? That should make bug fix sharing easier, right? //iveqy
Fredrik wrote:
On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote:
* Can corvid make another repo in the same server? (e.g. for the port to fltk-1.3)
Isn't it better to just make an other branch in the same repo? Can't everybody with commit access do that? That should make bug fix sharing easier, right?
How much does that complicate usage? Is it pretty much 1) name a new branch and 2) use the same hg commands as usual but add some branch argument?
On Mon, Jan 03, 2011 at 05:10:26PM +0000, corvid wrote:
Fredrik wrote:
On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote:
* Can corvid make another repo in the same server? (e.g. for the port to fltk-1.3)
Isn't it better to just make an other branch in the same repo? Can't everybody with commit access do that? That should make bug fix sharing easier, right?
How much does that complicate usage? Is it pretty much 1) name a new branch and 2) use the same hg commands as usual but add some branch argument?
I actually don't know, that's why I asked. I'm not that familiar with hg but with git. In git it would be very easy, and hg and git is very alike according to branching if I recall correct. However a hg guru should answear that question. In git you define your branch when you clone the repository and thereafter use git as usual. (of course you can change branches after a clone etc.). The main point is, that a bug found in dillo with fltk 2.0 that is also in dillo with fltk 1.3 should be able to be fixed with the same commit. This is known as the double maintenance problem. /iveqy
Fredrik wrote:
On Mon, Jan 03, 2011 at 05:10:26PM +0000, corvid wrote:
Fredrik wrote:
On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote:
* Can corvid make another repo in the same server? (e.g. for the port to fltk-1.3)
Isn't it better to just make an other branch in the same repo? Can't everybody with commit access do that? That should make bug fix sharing easier, right?
How much does that complicate usage? Is it pretty much 1) name a new branch and 2) use the same hg commands as usual but add some branch argument?
I actually don't know, that's why I asked. I'm not that familiar with hg but with git. In git it would be very easy, and hg and git is very alike according to branching if I recall correct.
However a hg guru should answear that question.
http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.ht... makes it sounds like either a new repository or a new branch would be a fairly standard response to our situation.
In git you define your branch when you clone the repository and thereafter use git as usual. (of course you can change branches after a clone etc.).
The main point is, that a bug found in dillo with fltk 2.0 that is also in dillo with fltk 1.3 should be able to be fixed with the same commit. This is known as the double maintenance problem.
One commit is visible in both branches?
On Mon, Jan 03, 2011 at 05:10:26PM +0000, corvid wrote:
Fredrik wrote:
On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote:
* Can corvid make another repo in the same server? (e.g. for the port to fltk-1.3)
Isn't it better to just make an other branch in the same repo? Can't everybody with commit access do that? That should make bug fix sharing easier, right?
How much does that complicate usage? Is it pretty much 1) name a new branch and 2) use the same hg commands as usual but add some branch argument?
I would go with a separate repo for fltk-1.3 development. It's still a branch, so we can use 3-way merging to keep things in sync with mainline. The only difference is that you don't get fltk-1.3 development stuff automatically when cloning the main repo - which I think is a good thing. Once it's ready we pull it over in the main repo. That's the same procedure we used for the CSS-experimental branch. Cheers, Johannes
Johannes wrote:
I would go with a separate repo for fltk-1.3 development. It's still a branch, so we can use 3-way merging to keep things in sync with mainline. The only difference is that you don't get fltk-1.3 development stuff automatically when cloning the main repo - which I think is a good thing. Once it's ready we pull it over in the main repo. That's the same procedure we used for the CSS-experimental branch.
Andreas added a repository for me. I've done most of the really mindless parts now, so now we merely need to do all of the hard parts!
On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote:
Johannes wrote:
I would go with a separate repo for fltk-1.3 development. It's still a branch, so we can use 3-way merging to keep things in sync with mainline. The only difference is that you don't get fltk-1.3 development stuff automatically when cloning the main repo - which I think is a good thing. Once it's ready we pull it over in the main repo. That's the same procedure we used for the CSS-experimental branch.
Andreas added a repository for me.
I've done most of the really mindless parts now, so now we merely need to do all of the hard parts!
Great. I hope we don't hit any showstoppers...
On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote:
Johannes wrote:
I would go with a separate repo for fltk-1.3 development. It's still a branch, so we can use 3-way merging to keep things in sync with mainline. The only difference is that you don't get fltk-1.3 development stuff automatically when cloning the main repo - which I think is a good thing. Once it's ready we pull it over in the main repo. That's the same procedure we used for the CSS-experimental branch.
Andreas added a repository for me.
I've done most of the really mindless parts now, so now we merely need to do all of the hard parts!
What are the coordinates of the repo? -- Cheers Jorge.-
On Fri, Jan 07, 2011 at 12:45:12PM -0300, Jorge Arellano Cid wrote:
On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote:
Johannes wrote:
I would go with a separate repo for fltk-1.3 development. It's still a branch, so we can use 3-way merging to keep things in sync with mainline. The only difference is that you don't get fltk-1.3 development stuff automatically when cloning the main repo - which I think is a good thing. Once it's ready we pull it over in the main repo. That's the same procedure we used for the CSS-experimental branch.
Andreas added a repository for me.
I've done most of the really mindless parts now, so now we merely need to do all of the hard parts!
What are the coordinates of the repo?
Check http://hg.dillo.org/ Cheers, Johannes
The downloads DPI is working fairly well now (although I have to resize it before it begins to display anything). It's nice to have something that compiles and runs!
participants (4)
-
corvid＠lavabit.com -
iveqy＠iveqy.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de