Les Mikesell wrote:
> Geoffrey wrote:
>>>> It's not the committing of code were are trying to track. We know
>>>> who committed the code. We are trying to figure out who executed
>>>> the 'svn update' on the production machine.
>>> You have a carbon-based error then; there is relatively little for
>>> Subversion (or any software package at all) to deal with that. You
>>> may want to consider a continuous build environment and require
>>> tagging of known good revisions prior to promotion to production
>>> (i.e. production only runs from a tag). It is really a bad idea to
>>> rely on knowing when/who ran 'svn up' into a production environment
>>> (think mixed revision working copies).
>> I completely agree and we aren't really relying on knowing who did the
>> update. It was a unique situation where neither person could recall
>> updating the identified file.
>> It was determined by the 'powers that be' that this was the proper
>> solution for updating the production environment, thus my hands are
>> pretty much tied.
> You might at least point out the folly of updating directly from the
> trunk when if the trunk was always production-ready you probably
> wouldn't be posting here.
>>> However, it's still a project communications issue, but by
>>> appropriate choice of policy, you can track the kind of "who broke
>>> the website" information that you seem to want... ;-)
>> Again, agreed.
> A branch/tag to release might make sense if you really want to use svn
> as the transport to production. Personally, I think it is better to
> update a staging site (perhaps just another WC on the box where you
> edit), do some testing, then rsync to the production server(s).
We do have a development machine. My personal preference was to update
from the development to the production by hand, but 'the powers that be'
wanted to update via svn.
Until later, Geoffrey
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-04 20:31:13 CET