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

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

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


From: Jeremy Shaw
Subject: [Gnu-arch-users] tla file-locking (good idea or bad idea?)
Date: Tue, 20 Jan 2004 13:15:19 -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)

Hello,

I would like to add file-locking to tla. Are there any strong
objections?  Should it be straight forward? Here is a brief story to
illustrate how I want to use file-locking.

We, have a central archive[1], which all developers can commit too (very
much like a standard cvs repository). I would like to be able to do
something like:

tla lock-file debian/changelog

To lock an individual file. This should prevent developers from
commiting changes that touch the changelog, but allow all other
changes.

Here's why this could be useful -- We have an autobuilder that can
check out a project, build the .debs, and upload the packages and
source to our local 'debian' repository. When the autobuilder checks
out a package, it automatically generates a new debian/changelog entry
in its local copy before it starts the build. If the build is
successful, it will commit the debian/changelog. If the build fails,
then it will send an email, and leave the debian/changelog alone.

The problem is -- what if someone commits a change to the
debian/changelog while the autobuilder is building? When the
autobuilder finishes, it will get a conflict when it attempts to
commit the changelog. There any many 'solutions' to this problem, but
they all have various tradeoffs. The solution we like best is to be
able to lock just the debian/changelog because it has the following
properties:

(1) The autobuilder can always commit the debian/changelog with out
    conflicts. (Some packages take 8+ hours to build -- having to
    throw out the whole build simply because the debian/changelog can
    not be commited is not acceptable).

(2) A developer can almost always commit. It is relatively rare for a
    developer to modify the debian/changelog. So, 99% of the time, it
    is fine for a developer to commit while the autobuilder is
    running. Using lock-revision would create long windows of time
    where a developer would like to commit a harmless change, but
    can't. A lock-file would only prevent commits the 1% of the time
    that it would cause trouble.

(3) A developer get immediate feedback as to whether their commit to
    debian/changelog is accepted or not.

(4) file-locks fit best with the existing autobuilder design. The
    current autobuilder is designed to be able to work with multiple
    different source control systems, but expects that they will all
    have a file-locking command. Perhaps a bad assumption -- but I
    didn't write it ;) However, as tla gains popularity, I think other
    people will find themselves in the same boat when they try to
    migrate their tools from cvs to tla.

I have not tried to convince you that file-locks are the best solution
to our problem -- that would require several more pages of
details. But, hopefully, I have given enough detail to explain why
someone might want to use file-locks.

Rephrasing my original questions: (a) if I submitted a (well written,
properly implemented) patch would it be considered for inclusion (b)
does anyone already know, off the top of their head, that implementing
file-locking is actually a very difficult task that should not be
attempted in the first place?

Jeremy Shaw.

[1] This isn't to say we don't use any of the distributed features of
tla.




reply via email to

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