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.
>> 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.
I'll migrate the workqueue path persistence over to these RSN.
Cheers,
-g
Received on 2010-05-10 07:38:12 CEST