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: Aaron Bentley
Subject: Re: [Gnu-arch-users] Re: tla file-locking (good idea or bad idea?)
Date: Wed, 21 Jan 2004 20:38:57 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

Jeremy Shaw wrote:

Hello,

Using branches has been suggested a few times, and I have discussed it
with some people, but I have never really come to satisfactory way of
doing it. But maybe I have some sort of mental block from too many
years of CVS.
[snip]

So, in brief, these are our basic requirements:

(1) the autobuilder must change its local copy of the debian/changelog
   before running dpkg-buildpackage (which can take hours to run).

(2) If the autobuilder completes successfully then it should commit
   its debian changelog.

(3) If the autobuilder fails to compile the package, it sends an error
   message and does NOT commit the changelog.

(4) The developer must be able to edit the debian/changelog in a
   manner that affects the autobuilder.

(5) The autobuilder must always be able to commit successfully if it
   completes the build.

(6) A developer should be allowed to commit changes to a package while
   the package is autobuilding, provided the commit will not affect
   the ability of the autobuilder to commit the debian/changelog.


Now, cleary (3) is the sticky point. If we commited a new changelog
even when the build failed, then we could simply do the commit at the
beginning, instead of waiting to see if the build failed or
not. However, our experience tells us this is not very desirable.

So, we have come up with 5 possible solutions:
[snip]

(4) Have the autobuilder build on its own branch

I am still exactly not clear on how this would work. I think maybe
there is a developers branch and an autobuilder branch. Before the
autobuilder builds, it tries to merge everything from the developers
branch, into its local branch. If there is a conflict, it dies and
sends an email?

If a developer wants to update the debian/changelog, then they have to
merge the debian/changelog from the autobuilder branch into the
developer branch, then edit and commit (in the developers branch). Of
course, if they doing this while the autobuilder is building, they
won't know they caused a problem until the next time the autobuilder
tries to compile that package?

This seems less desirable than the file-locking solution because you
still have to wait until the autobuilder is done with the package
before updating the changelog, but you don't get immediatly rejected.

Also, its valid (though somewhat frowned upon) to build the package by
hand and upload it. I am certain people will forget to merge the
debian/changelog from the autobuilder branch to the developer branch
before building. That won't cause any problems, except lost time. But
lost time still sucks.
[snip]

However, I am interested in how to solve this problem with branches,
because I think I might be missing something important. Or maybe I do
understand already, but just don't like the trade-offs?
Hi Jeremy,

I don't want to rain on your parade, but I think there's a fundamental problem here.
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.

Aaron




reply via email to

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