Ben Collins-Sussman <sussman@red-bean.com> wrote on 10/14/2004 09:37:16
AM:
>
> On Oct 14, 2004, at 9:31 AM, Mark Phippard wrote:
> >
> > The part I disagree with is not marking it conflicted and requiring
svn
> > resolve. I do not care how difficult that may be for a user to
> > understand. You cannot let someone create a conflict and not tell
> > anyone.
> > That is not helping at all.
> >
>
> In the case of hijacked files, VSS doesn't force people to deal with
> binary merges. Neither does Clearcase. Why should SVN be so much more
> unfriendly? I'm not saying we "don't tell the user", I'm saying, "we
> don't force the user through the current binary conflict resolution
> process." We scold the user, explain the backup file, and let them
> move on. Just like all these other locking VC systems do.
I have not worked a lot with VSS, but I am not sure I agree with your
take. I have worked with PVCS. With PVCS there are many different things
that could happen.
1) If you obtained your lock on the revision you actually had (non-HEAD),
then when you checked in, PVCS would create a branch for your check-in.
Ick.. I believe you would be warned about the branch creation.
2) Normally in PVCS you do a "Check out". This locks and copies the head
revision. If the file in your WC did not have the read-only bit set, it
would prompt you to overwrite. Hopefully, you would say No. You also
could just lock the revision, and not do a copy, but that would require
knowing a little bit more about the concepts.
I agree that neither of these deal with the situation, nor help you.
However, these products do not exactly have reputations as being very good
so why would we want to emulate them anyway? A big difference between svn
and VSS/PVCS is that svn knows what revision you have in your WC, and PVCS
doesn't. So svn can do a better job at knowing there is a problem and
alerting you.
I guess I would like to hear more about how you plan to inform the user.
That is the part that concerns me most. I also just do not see anything
wrong with having to run a command to say you have resolved the conflict.
I do not see where that is very difficult to do for a user. It is
certainly no more difficult than what they went through to hijack the file
in the first place.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 15:51:35 2004