Re: [alpine-devel] Why? ACF - million repos </sarcasm>
Branching is cheap-and-easy in git. It's not a hinderance to development
flow like it is in SVN.
I understand the release aspect of it now - hadn't thought of that. Will
have to give it some thought.
2011/3/31 Ted Trask <ttrask01_at_yahoo.com>
> If I have to tag the entire tree for a release, I don't like it.
> The reason they were put in separate repos was so that development could be
> independently. If I have to start doing lots of branching so I can release
> package and continue working on another, I don't think it's worth it.
> Separate independent repos for separate independent packages.
> ----- Original Message ----
> From: Timo Teräs <timo.teras_at_iki.fi>
> To: Ted Trask <ttrask01_at_yahoo.com>
> Cc: Natanael Copa <ncopa_at_alpinelinux.org>; jeremy_at_thomersonfamily.com;
> Alpine-devel <alpine-devel_at_lists.alpinelinux.org>
> Sent: Thu, March 31, 2011 9:26:48 AM
> Subject: Re: [alpine-devel] Why? ACF - million repos </sarcasm>
> On 03/31/2011 04:14 PM, Ted Trask wrote:
> > 1) Having one ACF git repo would save me some work when updating multiple
> > packages / releases, but it would add some overhead too. I have a
> tendency to
> > have unfinished work (uncommitted) on some packages while working on
> > Since git has only one stash (right?), it would be more difficult for me
> > maintain my tree.
> You can have several of them: man git-stash
> > 2) Also, building would be difficult. What tag would abuild pull? Some
> > will have untagged (not for release) mods that are older than tagged (for
> > release) mods for other packages. Would abuild pull separate tags from
> the repo
> > for each package?
> Basically you would have single version 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
> preferably 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 builds for earlier versions of
> > the old repos, 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 sounds like quite a
> > 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 obviously ncopa would have to do
> wacky stuff in abuild to make this work.
> - Timo
Received on Thu Mar 31 2011 - 09:53:56 UTC