[tei-council] Release process documentation

[Lou Burnard]

Personally, I find it very useful to be able to do a test build on my 
local machine before committing changes. The chances that some other 
change will have taken place that might affect the parts I am messing 
with, although not neglible, is still less than the probability that I 
will have messed up those parts in some embarrassingly obvious way which 
I'd rather not expose to the rest of the developer community :-)

But, to coin a phrase, your mileage may very well vary. And now that we 
have a pair of Jinxes I am finding the number of embarrassingly obvious 
errors I do have to expose is considerably reduced.


On 13/02/12 18:32, Sebastian Rahtz wrote:
>
> On 13 Feb 2012, at 17:56, Piotr Bański wrote:
>
>> Frankly, being mostly an end user of SVN, with its sacred policy of
>> "sync before you start your work", I'm a bit lost when it comes to the
>> interaction of SVN and continuous integration. I'm just wondering
>> whether, if we neglect telling the user (Council member, etc.) to sync
>> before work, we risk that other people's additions may get lost, given
>> that they go via SVN. I
>
> Using  SVN to edit the sources is separately from building.
> All the normal disciplines apply, like syncing before you start.
> SVN won't ever lose your work if you commit it - if it fails to commit,
> it will tell you why, and you'll need to recover.
>
> if you check out P5, and edit it over a period of a week Monday to Friday
> without committing changes, then you run a risk that I will have
> done work on Tuesday, and committed it the same day, so when you
> come to commit on Friday you may have a conflict. But this is normal
> version control stuff.
> --
> Stormageddon Rahtz
> Head of Information and Support Group, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> Sólo le pido a Dios
> que el futuro no me sea indiferente
>