>> Indeed, VC lacks a notion of "file with unresolved conflicts". Maybe
>> we should add it to the possible return values of vc-state.
> Yes, or it could perhaps be handled as another vc property of the
> file. It might be nice to have a "conflicted" flag in the modeline.
I don't think it needs to be a property. After all, if a file is
conflicted, it obviously will be neither up-to-date nor needs-patch
not needs-merge (nor locked, of course), so it makes sense to
have it as a state.
> I think it can be done with no need for an option:
> if people want updates, they can (with this patch) run vc-merge.
> if we try to commit and we're not uptodate, we can detect that as
> vc-cvs does.
That's what I made possible for vc-cvs.el (which originally had no
way to "stay local" and was thus unusable with slow repositories).
But it turns out that some people really enjoy being told right away
that the commit will fail (obviously their repository is zippy), so
Andre Spiegel introduced the vc-cvs-stay-local configuration variable.
I think it makes sense to have a vc-stay-local variable and have
both vc-cvs and vc-cvn obey it (while maybe still having their own
vc-foo-stay-local).
>> Good to hear. This is a serious problem with CVS where recovering the
>> `ancestor' and the `other' can be difficult. Now I think this is
>> a good argument for re-introducing a way to call ediff from VC
>> (in the current CVS code for Emacs, this has been removed and VC
>> relies on smerge-mode to provide the "call ediff" functionality).
> Yes, I think so. People probably should have the choice of either
> resolving by themselves using the conflict markers, or running
> emerge-files-with-ancestor on the files produced by svn.
... we'll probably need to add a new VC command and a new VC backend
operation that returns the three files so VC can call ediff properly.
> I think the way this should work is: when somebody tries to run
> vc-merge or vc-next-action, svn should check if the file is marked
> conflicted. If so, it says "Have you resolved the conflicts in this
> file? y/n" Saying y runs "svn resolve" to remove the conflict flag.
> n cancels.
I trust you on this one. I have no experience with it and hence
don't know what's a typical situation.
> Having said all this, there is still the drawback that vc is mostly
> file-at-a-time, whereas svn commits work better on sets of files or
> whole directories. I suppose psvn works well for that.
Yup, same thing as with CVS. Although while hacking Emacs, I must
say that I do a lot of file-at-a-time commits (because Emacs
is made of many mostly independent packages).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 1 01:04:57 2003