Ben Collins-Sussman wrote:
> Branko =?iso-8859-2?Q?=C8ibej?= <firstname.lastname@example.org> 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
> 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
> Of course, this starts to blur the line between `status' and
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.
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:12 2006