Noah Spurrier <noah@noah.org> wrote on 12/10/2007 03:33:14 PM:
> On 2007-12-10 15:20-0600, kmradke@rockwellcollins.com wrote:
> >
> >Not all "text" file formats will create a valid file when merged
> >on a line by line basis. Subversion is being used for a lot
> >more than source code now...
>
> Amen...
>
> >In this case, users can do a svn:needs-lock, or set the file
> >type to binary to disable the merging, but I have seen
> >a number of Rhapsody files become unloadable after what svn
> >thought was a valid merge operation. A simple svn up causes
> >them to lose all their changes. Only then do they realize
> >they should have been using locking.
> >
> >Kevin R.
>
> But this is not a very satisfying solution -- especially since it turns
the
> whole merge model of SVN on its head (no thank you visual source safe
server
> locks). Two engineers should be allowed to work on the same file without
> having to coordinate ahead of time. I would like SVN to force some
> coordination after the fact if it turns out that two engineers updated
the
> same file (and even if it thinks it can merge without help). Locking in
> version control is the work of the devil. Avoid his temptation.
>
> Of course, it's nice that SVN offers locking as an option for those who
need
> it. I just wish SVN offered the same option for automatic merging.
I agree that an option to enable/disable automatic merging for certain
file
extensions would be useful here. As you said, you then do not need
to rely on locking, but you can "save" the users from losing some of
their work.
(The work isn't really "lost", it just is garbled. Is there an easy
way to undo the automated merge? svn unupdate????)
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 10 22:41:39 2007