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

Re: Explanation on the conflict and "svn resolve" functionnality

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-04-06 18:17:06 CEST

[Please reply to the users@ list, not to me personally!]

On Tue, 2004-04-06 at 11:06, Alexis Boutillier wrote:
> I understand the solution that are in place.
> I agree it's is therefore a bettre solution than CVS but why is it
> possible to resolved a conflict without informing directly svn that the
> conflict is resolved ?

You misunderstand. Deleting the two tmpfiles *is* a way of "informing
svn directly that the conflict is resolved."

> I mean the tmpfiles are not under svn controle,

Actually, they *are* under svn control. They're listed in the
.svn/entries file, attached to the entry. That's why svn notices when
you've deleted them.

> I wonder why thoses files are not in the .svn/textbase entry because they
> are not related with the svn files or why there is not a conflicting state
> writen on the file in the .svn/entries ?

Of course there is. Look at the entry: it has a "conflicted" state
attached to it, as well as pointers to the two tmpfiles.

> I came to this because i run a cleanAll module that erase all files that
> are not under svn by using "svn status". I know it is a little hard way
> to do that but i left the svn directory with a modified file instead of a
> conflicting file.

Then perhaps your cleanAll module is a bit too over-zealous. If 'svn
status' reports that foo.c is conflicted, then your module should not
delete any '?' files that match the pattern 'foo.c.*'.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 6 18:18:59 2004

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

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