[Top][All Lists]
[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>