gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: tla file-locking (good idea or bad idea?)


From: Jeremy Shaw
Subject: Re: [Gnu-arch-users] Re: tla file-locking (good idea or bad idea?)
Date: Wed, 21 Jan 2004 18:30:14 -0800
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

[snip]

> Hi Jeremy,
> 
> I don't want to rain on your parade, but I think there's a fundamental 
> problem here.

Please rain all you want. I told you, I am pretty sure I am having
some sort of mental block.

> 1. You want a changelog.  Fine.
> 2. You want to commit that changelog in a revision if you have a 
> successful build.  Sure.
> 3. You want to commit the changelog to the *current* revision if a build 
> of a *recent* revision was successful.
> 
> I think that's why what you're doing is so hard to map onto Arch.  Because
> - The changelog entry belongs with the successfully-built revision, not 
> the current revision
> - You can't change history.  Not without a flux capacitor.
> 
> This suggests that there should be an incoming branch and a 
> successful-builds branch:
> tla get foo--incoming--0.9
> cp foo--incoming--0.9/changelog ~/
> rm -R foo--incoming--0.9
> tla get foo--builds--0.9
> cd foo--builds--0.9
> tla star-merge foo--incoming--0.9
> rm changelog.orig changelog.rej
> mv ~/changelog .
> 
> That's your CVS checkout-equivalent.  Yeah, I know.
> 
> 1. We want to avoid conflicts
> 2. changelog is the only file that differs in the builds branch.
> So we clobber the changelog with the one from the incoming branch.
> 
> Either committers are required to star-merge with the builds branch, or 
> you run the risk of losing the autobuilder entries from the standard 
> changeset
> 
> But tla can generate changelogs from your patch logs, so you may want to 
> use those instead.  You'll never lose the build info from them.
> 
> The rest of your procedure should work fine, minus locking, and you may 
> find there are advantages to having a builds branch that can always be 
> used to retrive the last buildable revision.  It's also trivial to 
> convert the lastest builds revision into the corresponding import revision.

Hrm, this almost works. The problem is, if the developer does the star
merge while the package is being autobuilt, then the autogenerated
debian/changelog won't be commited yet. If I create some mechanism
outside of tla that makes it easy to see if the package is build
autobuilt, then I could just make it a policy issue. Actually, I can
also add checks and send a warning email if the developer screws up.

I do like the benefits that your scheme offers. Specifically, a branch
that contains easily retrievable successful builds.

I will have to ponder this further and see what comes of it.

Thanks for you input!

Jeremy Shaw.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]