X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@lists.alpinelinux.org
Received: from jeremythomerson.com (mail.jeremythomerson.com [74.117.189.38])
	by lists.alpinelinux.org (Postfix) with ESMTP id AAA711EBFFA
	for <alpine-devel@lists.alpinelinux.org>; Thu, 31 Mar 2011 13:51:07 +0000 (UTC)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44])
	by jeremythomerson.com (Postfix) with ESMTP id 46E9F1C579
	for <alpine-devel@lists.alpinelinux.org>; Thu, 31 Mar 2011 08:59:34 -0500 (CDT)
Received: by wwa36 with SMTP id 36so2505966wwa.25
        for <alpine-devel@lists.alpinelinux.org>; Thu, 31 Mar 2011 06:51:04 -0700 (PDT)
Received: by 10.216.200.82 with SMTP id y60mr2621123wen.31.1301579464536; Thu,
 31 Mar 2011 06:51:04 -0700 (PDT)
X-Mailinglist: alpine-devel
Precedence: list
List-Id: Alpine Development <alpine-devel.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-devel+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-devel@lists.alpinelinux.org>
List-Help: <mailto:alpine-devel+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-devel+subscribe@lists.alpinelinux.org?subject=subscribe>
MIME-Version: 1.0
Reply-To: jeremy@thomersonfamily.com
Received: by 10.216.48.195 with HTTP; Thu, 31 Mar 2011 06:50:44 -0700 (PDT)
In-Reply-To: <4D948118.8050701@iki.fi>
References: <AANLkTindJPfApS9KrK_a2sJ4BxwDEk6+54b4zLAr=wJb@mail.gmail.com>
 <20110331141803.67f714de@ncopa-desktop.nor.wtbts.net> <899171.33677.qm@web130121.mail.mud.yahoo.com>
 <4D94795D.7040206@iki.fi> <678804.43665.qm@web130120.mail.mud.yahoo.com> <4D948118.8050701@iki.fi>
From: Jeremy Thomerson <jeremy@thomersonfamily.com>
Date: Thu, 31 Mar 2011 09:50:44 -0400
Message-ID: <AANLkTikXJVWfo0Yi9t8DeKUkUmWHywvFHDDiF1-Vx07i@mail.gmail.com>
Subject: Re: [alpine-devel] Why? ACF - million repos </sarcasm>
To: =?ISO-8859-1?Q?Timo_Ter=E4s?= <timo.teras@iki.fi>
Cc: Ted Trask <ttrask01@yahoo.com>, Natanael Copa <ncopa@alpinelinux.org>, 
	Alpine-devel <alpine-devel@lists.alpinelinux.org>
Content-Type: multipart/alternative; boundary=0016e6dab59ea17173049fc79547

--0016e6dab59ea17173049fc79547
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2011/3/31 Timo Ter=E4s <timo.teras@iki.fi>

> On 03/31/2011 04:14 PM, Ted Trask wrote:
> > 1) Having one ACF git repo would save me some work when updating multip=
le
> > packages / releases, but it would add some overhead too. I have a
> tendency to
> > have unfinished work (uncommitted) on some packages while working on
> others.
> > Since git has only one stash (right?), it would be more difficult for m=
e
> to
> > maintain my tree.
>
> You can have several of them: man git-stash
>

Use git branches.  When you start some chunk of work, "git checkout -b
mynewfeature master" creates mynewfeature branch from master.  Work on that=
,
but don't merge that branch to master.  Master can be the release-from
branch.


> > 2) Also, building would be difficult. What tag would abuild pull? Some
> packages
> > will have untagged (not for release) mods that are older than tagged (f=
or
> > 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.
>

Have abuild pull from master branch, or you can tag master branch with
release numbers.  "Not for release" stuff is in a "development" branch
(similar to answer for #1) rather than master.


> > 3) We should avoid breaking the old builds for earlier versions of
> alpine. Leave
> > 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
> 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 obviously ncopa would have to do
> wacky stuff in abuild to make this work.


Jeremy

--0016e6dab59ea17173049fc79547
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>
<div class=3D"gmail_quote">2011/3/31 Timo Ter=E4s <span dir=3D"ltr">&lt;<a =
href=3D"mailto:timo.teras@iki.fi">timo.teras@iki.fi</a>&gt;</span><br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div class=3D"im">On 03/31/2011 04:14 PM, Ted Trask wrote:<br>&gt; 1) Havin=
g one ACF git repo would save me some work when updating multiple<br>&gt; p=
ackages / releases, but it would add some overhead too. I have a tendency t=
o<br>

&gt; have unfinished work (uncommitted) on some packages while working on o=
thers.<br>&gt; Since git has only one stash (right?), it would be more diff=
icult for me to<br>&gt; maintain my tree.<br><br></div>You can have several=
 of them: man git-stash<br>

</blockquote>
<div>=A0</div>
<div>Use git branches.=A0 When you start some chunk of work, &quot;git chec=
kout -b mynewfeature master&quot; creates mynewfeature branch from master.=
=A0 Work on that, but don&#39;t merge that branch to master.=A0 Master can =
be the release-from branch.</div>


<div>=A0</div>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div class=3D"im">&gt; 2) Also, building would be difficult. What tag would=
 abuild pull? Some packages<br>&gt; will have untagged (not for release) mo=
ds that are older than tagged (for<br>&gt; release) mods for other packages=
. Would abuild pull separate tags from the repo<br>

&gt; for each package?<br></div>Basically you would have single version num=
ber and single tag for the<br>whole tree. You&#39;d need to bump only that =
and it&#39;d publish anything<br>changed in the whole tree.<br><br>The per-=
module versions would need to be in separate file, and be<br>

preferably automatically updated when you modified one of the files for<br>=
it. E.g. by git-hook on commit, or on just before tagging.<br>Alternatively=
, the submodule package version could be just the timestamp<br>it was last =
modified.<br>

</blockquote>
<div>=A0</div>
<div>Have abuild pull from master branch, or you can tag master branch with=
 release numbers.=A0 &quot;Not for release&quot; stuff is in a &quot;develo=
pment&quot; branch (similar to answer for #1) rather than master.</div>
<div>=A0</div>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div class=3D"im">&gt; 3) We should avoid breaking the old builds for earli=
er versions of alpine. Leave<br>&gt; the old repos, but only use a new, mer=
ged repo? I&#39;m a bit gunshy since the last<br>&gt; git updates broke all=
 of the aports for packages hosted on git.a.o.<br>

&gt;<br>&gt; So, I&#39;m ok with moving to one git repo, but it sounds like=
 quite a complication<br>&gt; for abuild. And, I&#39;m not going to be the =
one that has to implement it.<br><br></div>Yes, it&#39;d be new feature of =
abuild. And probably needs some thought if<br>

it&#39;s to be done.<br><br>This was just wish world I had. But obviously n=
copa would have to do<br>wacky stuff in abuild to make this work.</blockquo=
te>
<div>=A0</div>
<div>Jeremy</div></div>

--0016e6dab59ea17173049fc79547--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---