[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] vc-svn: vc-merge, avoid status checks

From: Martin Pool <mbp_at_sourcefrog.net>
Date: 2003-03-20 01:29:14 CET

On Wed, 19 Mar 2003 10:15:21 -0500, Stefan Monnier wrote:

> [ Note: I'm mostly unfamiliar with Subversion and still haven't looked
> at vc-svn.el, but I've hacked on VC quite a bit. ]

Hi Stefan!

> 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.

> It just does something like:
>
> (when (re-search-forward "Up-to-date check failed" nil t)
> (vc-file-setprop file 'vc-state 'needs-merge)
> (error (substitute-command-keys
> (concat "Up-to-date check failed: "
> "type \\[vc-next-action] to merge in changes"))))
>
> so instead of `yes' you have to say `C-x v v'.

Yes, I saw that after I posted. That looks like a good way to do it.

I thought that by using this sort of thing we could largely avoid ever
needing to run `svn status -uv'. Another option as you say would be
to add a vc-svn-stay-local.

The more I think about it, the more it seems that good emacs support,
as similar as possible to CVS, will be a great help in persuading
developers to switch. It will also help if the default configuration
of svn under emacs felt faster than CVS does.

> In vc-cvs.el the code is designed such that it is safe. I don't know
> if vc-svn.el does it as well, but if it doesn't, it should.

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.

>> +This calls `svn update'. In the case of conflicts, Subversion puts
>> +conflict markers into the file and leaves additional temporary files
>> +containing the `ancestor', `mine', and `other' files.
>
> 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.
 
>> +You may need to run `svn resolve' by hand once these conflicts have
>> +been resolved."
>
> Why is that ?

  http://svnbook.red-bean.com/book.html#svn-ch-3-sect-4.4

In addition (this is not really mentioned there) it can be confusing
in CVS if you try to update more changes into a file that already has
conflict markers.

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.

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.

Regards,

-- 
Martin
<bje> I want to build distcc boxes that I can scatter through the
house like BOSE speakers :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 20 01:41:16 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.