2011/3/31 Ted Trask <ttrask01@yahoo.com>

If I have to tag the entire tree= for a release, I don't like it.

The reason they were put in sep= arate repos was so that development could be done
independently. If I have to start doing lots of branching so I can release = one
package and continue working on another, I don't think it's = worth it.

Separate independent repos for separate independent packag= es.

Ted

----- Original Message ----
Fro= m: Timo Ter=E4s <timo.teras@iki.fi<= /a>>
To: Ted Trask <ttrask01= @yahoo.com>
Cc: Natanael Copa <ncopa@alpine= linux.org>; jeremy@tho= mersonfamily.com;
Alpine-devel <alpine-devel@lists.alpinelinux.org>

Sent: Thu, March 31, 2011 9:26:48 AM
Subject: Re: [alp= ine-devel] Why? ACF - million repos </sarcasm>

On 03/31/2011 04:14 PM, Ted Trask wrote:
> 1) Havin= g one ACF git repo would save me some work when updating multiple
> p= ackages / releases, but it would add some overhead too. I have a tendency t= o
> have unfinished work (uncommitted) on some packages while working on o= thers.
> Since git has only one stash (right?), it would be more diff= icult for me to
> maintain my tree.

You can have several of th= em: man git-stash

> 2) Also, building would be difficult. What tag would abuild pull? = Some packages
>
> will have untagged (not for release) mods tha= t are older than tagged (for
> release) mods for other packages. Woul= d abuild pull separate tags from the repo
>
> for each package?

Basically you would have single versi= on number and single tag for the
whole tree. You'd need to bump only= that and it'd publish anything
changed in the whole tree.

The per-module versions would need to be in separate file, and be
prefer= ably automatically updated when you modified one of the files for
it. E.= g. by git-hook on commit, or on just before tagging.
Alternatively, the = submodule package version could be just the timestamp
it was last modified.

> 3) We should avoid breaking the old build= s for earlier versions of alpine.
>Leave
>
> the old repo= s, but only use a new, merged repo? I'm a bit gunshy since the last
>
> git updates broke all of the aports for packages hosted on git= .a.o.
>
> So, I'm ok with moving to one git repo, but it so= unds like quite a complication
>
> for abuild. And, I'm not= going to be the one that has to implement it.

Yes, it'd be new feature of abuild. And probably needs some thought= if
it's to be done.

This was just wish world I had. But obvi= ously ncopa would have to do
wacky stuff in abuild to make this work.
- Timo