monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] validate checkins


From: Brian May
Subject: Re: [Monotone-devel] validate checkins
Date: Thu, 30 Nov 2006 10:03:54 +1100
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)

>>>>> "Nathaniel" == Nathaniel Smith <address@hidden> writes:

    Nathaniel> (a) is really not specific to line-endings; people want
    Nathaniel> to enforce all kinds of style guidelines.  ("No tabs",
    Nathaniel> "no lines longer than 78 characters", "quasi-sane
    Nathaniel> indentation", ...)  This is a bit of a sticky issue in
    Nathaniel> a DVCS, because you cannot straightforwardly enforce
    Nathaniel> any such rules in the same way you can when there is a
    Nathaniel> central server validating all checkins.  Also, the
    Nathaniel> monotone philosophy is that validation is _generally_
    Nathaniel> speaking something that you want to do _after_ checkin
    Nathaniel> (but before merge), rather than before.  Some people
    Nathaniel> have made the argument that very simple checks like
    Nathaniel> scanning for tabs are most conveniently handled before
    Nathaniel> checkin, and I can see the point.  In any case, if
    Nathaniel> there are people who want to add pre-commit checking to
    Nathaniel> monotone, they should start a different thread to talk
    Nathaniel> about it.  Line-endings are mostly a distraction to
    Nathaniel> this.

I would prefer checks occur before checkin, simply because otherwise,
a simple one line change to, say a 1000 line file could end up being a
1000 line diff + another 1000 line diff to undo the changes from the
first revision, which could be rather confusing when trying to work
out what really changed.

The difficulty I see is getting consistent policies on a per branch
and/or per repository basis, as hooks are setup for each user.

So if one user setup their hooks to commit text files in one format
and another user setup their hooks to commit in another format, this
would kind of defeat the purpose.
-- 
Brian May <address@hidden>




reply via email to

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