Ben Collins-Sussman <sussman@red-bean.com> wrote on 10/13/2004 05:16:45
PM:
>
> On Oct 13, 2004, at 5:06 PM, Mark Phippard wrote:
>
> >> The goal here is that the "non VC" user never ever sees a Conflict.
> >> We
> >> don't want non-techies to see a "C" next to a file, to have to
> >> understand the 3 fulltexts, or the 'svn resolved' command. Go look
at
> >> the 'hijack' section of the UI document to understand this
motivation.
> >
> > I understood the motivation, I just didn't understand how the proposal
> > solved it. Also, what I am mainly interested in is that if someone
> > uses
> > this feature with say a .c file, that I think it ought to work the way
> > it
> > currently does. If the file is not mergeable, then I have no
> > objection to
> > making it work differently. Although, personally, I think it should
> > raise
> > the conflict and require you to make it resolved.
> >
>
> I'll work to clarify the doc. What I'm proposing is this:
>
> * user hijacks a read-only 'svn:needs-lock' file, edits it
> * user tries to commit, gets error: "you need a lock!"
> * user tries to lock, gets error: "you need to update!"
> * user runs 'svn up':
> A. if file is mergeable, merge it.
> B. if file is unmergable, don't produce conflict, just back up
> repos version.
>
>
> So I *do* agree with you, regarding scenario (A) above. The deal is,
> scenario (A) isn't very likely to happen. If the file were mergeable,
> why did the admin put an 'svn:needs-lock' property on it? ;-)
I think scenario A will be more common than you think. There are going to
be a lot of corporate shops that are going to want (or at least be forced
by pointy haired bosses) to use Subversion as a "Locking" version control
system a la PVCS or SourceSafe. If you are working in that environment,
this scenario will eventually happen.
As for Scenario B, I just do not understand why you would not generate a
conflict, when there is one. How are we helping anyone by not bringing
this to the user's attention? Suppose I have rev 1 of a graphic for an ad
that has a price in it. Sometime along the way, another artist changes
the price in the ad. I am now assigned to change the color of the text. I
still have version 1 in my WC and go through what you describe above to
change the color. And commit. I have now produced a version of the
graphic with the wrong price, and frankly the tool has done nothing to
tell anyone there was a problem. Having the backup will be of little
comfort.
If people are using version control, there must be a reason. We can make
it as easy as possible, but we should not sacrifice the basic features
that are needed. These users are going to be using GUI's of some kind,
and it should be possible to deal with. I think TSVN handles this pretty
well, as an example.
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 03:18:13 2004