[tei-council] Commits, builds, errors and Jenkins

[James Cummings]

On 20/04/11 05:03, stuart yeates wrote:
> On 20/04/11 10:23, Martin Holmes wrote:
>> What this means in practice is that, if there are many of us making
>> changes and commits, we will only see the results of our commits (in
> While I admit that this is a hypothetical danger, I'm not convinced at
> how real it is, whether it's real enough that we should be worrying about.

I'd agree with Stuart. Historically there have only been a small 
number of people committing at any one point, and even in that 
case, watching the version numbers of commit messages mitigates 
this.  One can also do SVN locking, if you are worried that 
someone might be about to make changes on the files you are 
working on.  'svn lock' locks the file for any other commits 
until you commit or 'svn unlock'.  But I don't think we really 
need that either.

> Requiring those wanting to make textual changes to the guidelines to
> have a full build environment seems like it raises technical barriers to
> non-technical tasks, reducing the pool of people to do the work.

A full build environment is *not* required for those wanting to 
make textual changes to the Guidelines.  Martin is undertaking to 
do a full build because he wants to make sure he can understand 
and eventually duplicate the process.  I'm going to be doing a 
bunch of documentary (non-schema affecting) changes and certainly 
not going to do a full build in between each of these.  I will 
make the change in the Guidelines text, do an xmlwf to check I've 
not made any xml typos, possibly validate the file (but if I'm 
just changing a few words probably not), and svn commit. The 
point about having a continuous integration server like Jenkins 
is I should then be able to see that my changes are still valid 
and also see the result of them in an HTML rendering without 
needing to have a full build environment or similar on my 
computer.  The only required things for those doing non-schema 
related is a subversion client and a text editor.  (Ok, an XML 
editor makes more sense, and yes of course I happen to have a 
full build environment on several computers, but I only rarely 
actually run make before committing.) I'm not saying doing a full 
test on _any_ changes is a bad idea, quite the contrary, but it 
certainly shouldn't be required.

-James


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford