Daniel Noll wrote:
> Byron Brummer wrote:
>> Your model makes the assumption that anything checked in by
>> a developer automatically "works" and thus anything else
>> can be piled on top and keep going forward. In the real
>> world even if the change *does* work *exactly* as everyone
>> intended, there are a ton of other reasons it may need to
>> get pulled back. The design team didn't like out it looked
>> when they finally saw it, the legal department has an issue
>> with it, some contract that was in the works failed to go
>> through and it legally *can't* be put in production yet (or
>> maybe ever, but ya don't know). Etc, etc.
>
> Maybe it shouldn't have been checked in yet, if the relevant parties
> hadn't approved it. What I would do in this contrived example is to
> send the diff to the parties who need to approve it, and if it gets
> through, then commit it.
>
If you think something shouldn't be checked in because it is not
finalized yet, I
think you've missed the point of a revision control system where you can
recall any state you want and review the changes before or after that state.
If anyone wants diffs they can easily generate them. Subversion's tags
can be used to give permanent names to these states. However, since tags
are end points in subversion, it is not particularly handy to track a file's
history through many tagged states without knowing which tags to
compare ahead of time.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 23 05:31:22 2007