Re: CVS update: subversion/subversion/libsvn_wc status.c Makefile.am wc.h

[Ben Collins-Sussman <su...@newton.collab.net>]

Branko =?iso-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:

> I thought it should be possible for status to report that a file
> is currently in conflict? After an update, of course. Oh, that would
> be nice! Let's not have any ">>>>>>"'s in working copy files, let's
> not have to update to see conflicts ...

Sounds like some bells and whistles -- a good idea, but of course this
goes beyond what CVS does, which is all we're trying to do at this
moment.  

Right now, the `status' command just grabs a version number from the
repository.  Perhaps we can eventually pass an extra flag which makes
it fetch the *entire* repos file and attempt to merge it in a scratch
area.

Of course, this starts to blur the line between `status' and
`update'.  Suppose the status command tells you that your locally
modified file is currently in conflict.  What then?  What are you
going to do about it?  Do you expect to see the conflict in a scratch
area?  Are you going to update that one file to see the conflict?  I'm
not sure I understand what itch is being scratched.

Re: CVS update: subversion/subversion/libsvn_wc status.c Makefile.am wc.h

[Branko Čibej <br...@xbc.nu>]

Ben Collins-Sussman wrote:

> Branko =?iso-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> 
>> I thought it should be possible for status to report that a file
>> is currently in conflict? After an update, of course. Oh, that would
>> be nice! Let's not have any ">>>>>>"'s in working copy files, let's
>> not have to update to see conflicts ...
> 
> 
> Sounds like some bells and whistles -- a good idea, but of course this
> goes beyond what CVS does, which is all we're trying to do at this
> moment.  
> 
> Right now, the `status' command just grabs a version number from the
> repository.  Perhaps we can eventually pass an extra flag which makes
> it fetch the *entire* repos file and attempt to merge it in a scratch
> area.
> 
> Of course, this starts to blur the line between `status' and
> `update'.

Notice what I said above: "After an update, of course."

I see it working like this: when update detects a conflict, it stores 
the current repository version of the file somewhere in the admin 
directory, probably near the stored original version. Status would just 
look if that locally stored version exists, and subsequent updates would 
pull in a new version, or remove it if the conflict goes away. Extra 
bonus: you can do a three-way merge locally.

>   Suppose the status command tells you that your locally
> modified file is currently in conflict.  What then?  What are you
> going to do about it?  Do you expect to see the conflict in a scratch
> area?  Are you going to update that one file to see the conflict?  I'm
> not sure I understand what itch is being scratched.

a) You don't have to do an update to check if you currently have any 
conflics; b) you can still compile in the local copy without tripping 
over those wakas; c) works well for binary files that can have special 
merge tools; d) etcetera ad nauseam.


-- 
Brane �ibej
    home:   <br...@xbc.nu>           http://www.xbc.nu/brane/
     ACM:   <br...@acm.org>          http://www.acm.org/