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

Re: conflict-storage, and filenames

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 10 May 2010 10:56:51 +0200

On Mon, May 10, 2010 at 01:37:36AM -0400, Greg Stein wrote:
> On Sun, May 9, 2010 at 18:21, Bert Huijben <bert_at_qqmail.nl> wrote:
> >...
> >> From: Stefan Sperling [mailto:stsp_at_elego.de]
> >...
> >> > As Bert explained, we need to remove them when the user runs "svn
> >> > resolved". He also noted that (somtimes) it is possible manually
> >> > resolve a conflict by removing all the conflict files (a potentially
> >> > debatable feature).
> >>
> >> I see. Then let's just add another field to the skel.
> >> I guess we can store this within the conflict-type-specific data?
> I believe so. It doesn't seem to apply to the OPERATION sub-skel. Each
> type of conflict has a different set of in-working-copy files that it
> may need to record.


> I'll update conflict-storage "soon". Not really there right now.

OK. I'll also try to update it if I find some time.

> >> Storing the basename should be enough since we can assume the file
> >> will be put into the same directory as the conflicted file, right?
> >
> > For text conflicts this would be the case, but for a property conflict on a
> > directory it would be harder to tell where the file is located. (What if the
> > directory is missing?). Greg suggested adding a wcroot-relative path on IRC.
> Right. The wcroot is definitely known, and any path is
> reachable/computable from there. We don't need to worry about
> "basename relative to WHAT directory?"

> I've written two functions: svn_wc__db_to_relpath() and
> svn_wc__db_from_relpath(). These can/should be used for all
> abspath/relpath conversions within libsvn_wc when a path needs to be
> persisted. Using them for *other* purposes is verboten.

Practicing your German in preparation for your trip to Berlin is
definitely a good idea :)

Received on 2010-05-10 10:57:29 CEST

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