You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2007/09/06 17:14:53 UTC
conflict resolver callback question / enhancement request
Hi,
I'm currently implementing the new conflict resolver callback in TSVN.
And I'm not sure if I simply don't quite understand the data I get or
there's something missing:
how do I know whether the conflict is in the file contents or the file
properties? Or is the callback not invoked for property conflicts? If it
is, shouldn't there be some flag in the svn_wc_conflict_description_t
struct indicating whether it's a file or property conflict (or both)?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Stefan Küng <to...@gmail.com>.
David Glasser wrote:
> On 10/12/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
>> On 9/6/07, Stefan Küng <to...@gmail.com> wrote:
>>
>>>> And yes, you're right: we should expand the conflict_description_t to
>>>> indicate text vs. prop conflict.
>>> And please consider not just a boolean for this. The property name would
>>> be very useful: the svn: properties are basically text and could be
>>> merged with the right tool instead of just keeping either the repository
>>> or local props.
>>
>> Here's my interactive-prop-conflict design. Code forthcoming.
>> It should make both Mark and Stefan happy.
>>
>> The only property actions are 'set' and 'delete'. Thus there are only
>> 2 types of prop conflicts:
>>
>> - two people try to set the same property to different values
>> - one person sets a prop, another person deletes it
>>
>> (Both people deleting a prop is a mergeable change, as is two propsets
>> to the same value.)
>>
>> In svn 1.4, when a property conflict happens, libsvn_wc just marks the
>> file conflicted and creates a "foo.c.prej" file that describes the
>> conflict. (The contents of the file are something like: "Hey, your
>> local edit sets the property 'foo' to 'bar', but the repository wants
>> to set 'foo' to 'baz'.")
>>
>>
>> Proposal to extend our interactive conflict callback for props:
>>
>> - Invoke conflict callback for *each* property conflict discovered.
>> This means that the conflict callback might be invoked many times
>> on the same path -- e.g. once for a text conflict, and N more
>> times for N property conflicts on the same file.
>>
>> - svn_wc_conflict_description_t is expanded to describe a property
>> conflict:
>>
>> - add new fields, and only set them when we're describing a
>> prop-conflict:
>>
>> const char *propname;
>> svn_string_t *base_propvalue;
>> svn_string_t *their_propvalue;
>> svn_string_t *my_propvalue;
>>
>> - the "action" field is either 'edit' or 'delete'... (and
>> 'their_propvalue' is correspondingly non-NULL or NULL.)
>>
>> - the "reason" field is either 'edited' or 'deleted'... (and
>> 'my_propvalue) is correspondingly non-NULL or NULL.)
>>
>> - svn_wc_conflict_result_t is expanded to describe the resolution of
>> a property conflict:
>>
>> - add a new field:
>>
>> svn_string_t *merged_propvalue;
>>
>> - add new enums:
>>
>> svn_wc_conflict_result_choose_base_propvalue
>> svn_wc_conflict_result_choose_their_propvalue
>> svn_wc_conflict_result_choose_my_propvalue
>> svn_wc_conflict_result_choose_mergede_propvalue
>>
>> As one would expect, returning one of these new result-codes tells
>> libsvn_wc to install one of the three original propvalues, or
>> to use the new 'merged_propvalue' that the callback is providing.
>>
>> - returning 'svn_wc_conflict_result_conflicted' tells libsvn_wc
>> to just mark the file conflicted, create the usual .prej file,
>> and allow conflict resolution to be postponed for later.
>
> Will the API provide a way for a callback implementor to get a
> diff3-merge-style merge of line-based props (eg svn:ignore), or do the
> callbacks all have to implement that themselves?
I think the clients should do that themselves. After all, not all
properties are pure text (it's possible to set binary properties).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by David Glasser <gl...@davidglasser.net>.
On 10/12/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 9/6/07, Stefan Küng <to...@gmail.com> wrote:
>
> > > And yes, you're right: we should expand the conflict_description_t to
> > > indicate text vs. prop conflict.
> >
> > And please consider not just a boolean for this. The property name would
> > be very useful: the svn: properties are basically text and could be
> > merged with the right tool instead of just keeping either the repository
> > or local props.
>
>
> Here's my interactive-prop-conflict design. Code forthcoming.
> It should make both Mark and Stefan happy.
>
> The only property actions are 'set' and 'delete'. Thus there are only
> 2 types of prop conflicts:
>
> - two people try to set the same property to different values
> - one person sets a prop, another person deletes it
>
> (Both people deleting a prop is a mergeable change, as is two propsets
> to the same value.)
>
> In svn 1.4, when a property conflict happens, libsvn_wc just marks the
> file conflicted and creates a "foo.c.prej" file that describes the
> conflict. (The contents of the file are something like: "Hey, your
> local edit sets the property 'foo' to 'bar', but the repository wants
> to set 'foo' to 'baz'.")
>
>
> Proposal to extend our interactive conflict callback for props:
>
> - Invoke conflict callback for *each* property conflict discovered.
> This means that the conflict callback might be invoked many times
> on the same path -- e.g. once for a text conflict, and N more
> times for N property conflicts on the same file.
>
> - svn_wc_conflict_description_t is expanded to describe a property
> conflict:
>
> - add new fields, and only set them when we're describing a
> prop-conflict:
>
> const char *propname;
> svn_string_t *base_propvalue;
> svn_string_t *their_propvalue;
> svn_string_t *my_propvalue;
>
> - the "action" field is either 'edit' or 'delete'... (and
> 'their_propvalue' is correspondingly non-NULL or NULL.)
>
> - the "reason" field is either 'edited' or 'deleted'... (and
> 'my_propvalue) is correspondingly non-NULL or NULL.)
>
> - svn_wc_conflict_result_t is expanded to describe the resolution of
> a property conflict:
>
> - add a new field:
>
> svn_string_t *merged_propvalue;
>
> - add new enums:
>
> svn_wc_conflict_result_choose_base_propvalue
> svn_wc_conflict_result_choose_their_propvalue
> svn_wc_conflict_result_choose_my_propvalue
> svn_wc_conflict_result_choose_mergede_propvalue
>
> As one would expect, returning one of these new result-codes tells
> libsvn_wc to install one of the three original propvalues, or
> to use the new 'merged_propvalue' that the callback is providing.
>
> - returning 'svn_wc_conflict_result_conflicted' tells libsvn_wc
> to just mark the file conflicted, create the usual .prej file,
> and allow conflict resolution to be postponed for later.
Will the API provide a way for a callback implementor to get a
diff3-merge-style merge of line-based props (eg svn:ignore), or do the
callbacks all have to implement that themselves?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Erik Huelsmann <eh...@gmail.com>.
On 10/12/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 10/12/07, Erik Huelsmann <eh...@gmail.com> wrote:
>
> > Actually, it *is* a trivial thing to add, since I added an API to use
> > our internal diff/merge algorithm on in-memory text blocks.
>
> And how would we know if the propvalues (svn_string_t) are
> contextually mergeable?
You don't, but if you want to put the burden on the client to do the
merge, at least we provide the api's to do the merges in our diff lib.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Ben Collins-Sussman <su...@red-bean.com>.
I've got a big patch in progress here, but it's causing some segfaults
in merge_tests, probably some simple error I made somewhere. I'll
post it here so others can look at it if they're curious. Later
tonight, I'll fix the errors and commit this as a starting point.
(This patch just expands the API for prop-conflicts, but doesn't
actually *use* the prop-conflict stuff yet.)
Re: conflict resolver callback question / enhancement request
Posted by David Glasser <gl...@davidglasser.net>.
On 10/12/07, Stefan Küng <to...@gmail.com> wrote:
> David Glasser wrote:
> > On 10/12/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> >> On 10/12/07, Erik Huelsmann <eh...@gmail.com> wrote:
> >>
> >>> Actually, it *is* a trivial thing to add, since I added an API to use
> >>> our internal diff/merge algorithm on in-memory text blocks.
> >> And how would we know if the propvalues (svn_string_t) are
> >> contextually mergeable?
> >
> > I was thinking about this for a bit today. I suspect that people
> > would in fact appreciate it if svn:include values could be mergeable
> > in the CLI client.
> >
> > Perhaps a config value for mergeable properties, defaulting to
> > svn:include and svn:externals?
>
> svn:include ?
> Did I miss the introduction of a new special property?
> What does that property do? Is it somewhere documented?
> I couldn't find anything about that property.
Er, svn:ignore.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Stefan Küng <to...@gmail.com>.
David Glasser wrote:
> On 10/12/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
>> On 10/12/07, Erik Huelsmann <eh...@gmail.com> wrote:
>>
>>> Actually, it *is* a trivial thing to add, since I added an API to use
>>> our internal diff/merge algorithm on in-memory text blocks.
>> And how would we know if the propvalues (svn_string_t) are
>> contextually mergeable?
>
> I was thinking about this for a bit today. I suspect that people
> would in fact appreciate it if svn:include values could be mergeable
> in the CLI client.
>
> Perhaps a config value for mergeable properties, defaulting to
> svn:include and svn:externals?
svn:include ?
Did I miss the introduction of a new special property?
What does that property do? Is it somewhere documented?
I couldn't find anything about that property.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by David Glasser <gl...@davidglasser.net>.
On 10/12/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 10/12/07, Erik Huelsmann <eh...@gmail.com> wrote:
>
> > Actually, it *is* a trivial thing to add, since I added an API to use
> > our internal diff/merge algorithm on in-memory text blocks.
>
> And how would we know if the propvalues (svn_string_t) are
> contextually mergeable?
I was thinking about this for a bit today. I suspect that people
would in fact appreciate it if svn:include values could be mergeable
in the CLI client.
Perhaps a config value for mergeable properties, defaulting to
svn:include and svn:externals?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 10/12/07, Erik Huelsmann <eh...@gmail.com> wrote:
> Actually, it *is* a trivial thing to add, since I added an API to use
> our internal diff/merge algorithm on in-memory text blocks.
And how would we know if the propvalues (svn_string_t) are
contextually mergeable?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Erik Huelsmann <eh...@gmail.com>.
On 10/12/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 10/12/07, Stefan Küng <to...@gmail.com> wrote:
>
> > > svn_wc_conflict_result_choose_base_propvalue
> > > svn_wc_conflict_result_choose_their_propvalue
> > > svn_wc_conflict_result_choose_my_propvalue
> > > svn_wc_conflict_result_choose_mergede_propvalue
> >
> > Is a new enum really necessary? I mean, the callback doesn't get called
> > for two conflicts at the same time (file and prop conflict). So the
> > existing enum should be fine.
>
> Good point! Let's re-use them; I'll just update the docstrings accordingly.
>
> And yes, it will be the jobs of clients to do contextual merges of
> property values. No svn core libraries are able to do this, and it's
> not a trivial thing to add.
Actually, it *is* a trivial thing to add, since I added an API to use
our internal diff/merge algorithm on in-memory text blocks.
Bye,
Erik.
Re: conflict resolver callback question / enhancement request
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 10/12/07, Stefan Küng <to...@gmail.com> wrote:
> > svn_wc_conflict_result_choose_base_propvalue
> > svn_wc_conflict_result_choose_their_propvalue
> > svn_wc_conflict_result_choose_my_propvalue
> > svn_wc_conflict_result_choose_mergede_propvalue
>
> Is a new enum really necessary? I mean, the callback doesn't get called
> for two conflicts at the same time (file and prop conflict). So the
> existing enum should be fine.
Good point! Let's re-use them; I'll just update the docstrings accordingly.
And yes, it will be the jobs of clients to do contextual merges of
property values. No svn core libraries are able to do this, and it's
not a trivial thing to add.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Stefan Küng <to...@gmail.com>.
Ben Collins-Sussman wrote:
> Here's my interactive-prop-conflict design. Code forthcoming.
> It should make both Mark and Stefan happy.
>
> The only property actions are 'set' and 'delete'. Thus there are only
> 2 types of prop conflicts:
>
> - two people try to set the same property to different values
> - one person sets a prop, another person deletes it
>
> (Both people deleting a prop is a mergeable change, as is two propsets
> to the same value.)
>
> In svn 1.4, when a property conflict happens, libsvn_wc just marks the
> file conflicted and creates a "foo.c.prej" file that describes the
> conflict. (The contents of the file are something like: "Hey, your
> local edit sets the property 'foo' to 'bar', but the repository wants
> to set 'foo' to 'baz'.")
>
>
> Proposal to extend our interactive conflict callback for props:
>
> - Invoke conflict callback for *each* property conflict discovered.
> This means that the conflict callback might be invoked many times
> on the same path -- e.g. once for a text conflict, and N more
> times for N property conflicts on the same file.
>
> - svn_wc_conflict_description_t is expanded to describe a property
> conflict:
>
> - add new fields, and only set them when we're describing a
> prop-conflict:
>
> const char *propname;
> svn_string_t *base_propvalue;
> svn_string_t *their_propvalue;
> svn_string_t *my_propvalue;
>
> - the "action" field is either 'edit' or 'delete'... (and
> 'their_propvalue' is correspondingly non-NULL or NULL.)
>
> - the "reason" field is either 'edited' or 'deleted'... (and
> 'my_propvalue) is correspondingly non-NULL or NULL.)
>
> - svn_wc_conflict_result_t is expanded to describe the resolution of
> a property conflict:
>
> - add a new field:
>
> svn_string_t *merged_propvalue;
>
> - add new enums:
>
> svn_wc_conflict_result_choose_base_propvalue
> svn_wc_conflict_result_choose_their_propvalue
> svn_wc_conflict_result_choose_my_propvalue
> svn_wc_conflict_result_choose_mergede_propvalue
Is a new enum really necessary? I mean, the callback doesn't get called
for two conflicts at the same time (file and prop conflict). So the
existing enum should be fine.
> As one would expect, returning one of these new result-codes tells
> libsvn_wc to install one of the three original propvalues, or
> to use the new 'merged_propvalue' that the callback is providing.
>
> - returning 'svn_wc_conflict_result_conflicted' tells libsvn_wc
> to just mark the file conflicted, create the usual .prej file,
> and allow conflict resolution to be postponed for later.
Looks good!
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Mark Phippard <ma...@gmail.com>.
On 10/12/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 9/6/07, Stefan Küng <to...@gmail.com> wrote:
>
> > > And yes, you're right: we should expand the conflict_description_t to
> > > indicate text vs. prop conflict.
> >
> > And please consider not just a boolean for this. The property name would
> > be very useful: the svn: properties are basically text and could be
> > merged with the right tool instead of just keeping either the repository
> > or local props.
>
>
> Here's my interactive-prop-conflict design. Code forthcoming.
> It should make both Mark and Stefan happy.
>
> The only property actions are 'set' and 'delete'. Thus there are only
> 2 types of prop conflicts:
>
> - two people try to set the same property to different values
> - one person sets a prop, another person deletes it
>
> (Both people deleting a prop is a mergeable change, as is two propsets
> to the same value.)
>
> In svn 1.4, when a property conflict happens, libsvn_wc just marks the
> file conflicted and creates a "foo.c.prej" file that describes the
> conflict. (The contents of the file are something like: "Hey, your
> local edit sets the property 'foo' to 'bar', but the repository wants
> to set 'foo' to 'baz'.")
>
>
> Proposal to extend our interactive conflict callback for props:
>
> - Invoke conflict callback for *each* property conflict discovered.
> This means that the conflict callback might be invoked many times
> on the same path -- e.g. once for a text conflict, and N more
> times for N property conflicts on the same file.
>
> - svn_wc_conflict_description_t is expanded to describe a property
> conflict:
>
> - add new fields, and only set them when we're describing a
> prop-conflict:
>
> const char *propname;
> svn_string_t *base_propvalue;
> svn_string_t *their_propvalue;
> svn_string_t *my_propvalue;
>
> - the "action" field is either 'edit' or 'delete'... (and
> 'their_propvalue' is correspondingly non-NULL or NULL.)
>
> - the "reason" field is either 'edited' or 'deleted'... (and
> 'my_propvalue) is correspondingly non-NULL or NULL.)
>
> - svn_wc_conflict_result_t is expanded to describe the resolution of
> a property conflict:
>
> - add a new field:
>
> svn_string_t *merged_propvalue;
>
> - add new enums:
>
> svn_wc_conflict_result_choose_base_propvalue
> svn_wc_conflict_result_choose_their_propvalue
> svn_wc_conflict_result_choose_my_propvalue
> svn_wc_conflict_result_choose_mergede_propvalue
>
> As one would expect, returning one of these new result-codes tells
> libsvn_wc to install one of the three original propvalues, or
> to use the new 'merged_propvalue' that the callback is providing.
>
> - returning 'svn_wc_conflict_result_conflicted' tells libsvn_wc
> to just mark the file conflicted, create the usual .prej file,
> and allow conflict resolution to be postponed for later.
This looks fine to me.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 9/6/07, Stefan Küng <to...@gmail.com> wrote:
> > And yes, you're right: we should expand the conflict_description_t to
> > indicate text vs. prop conflict.
>
> And please consider not just a boolean for this. The property name would
> be very useful: the svn: properties are basically text and could be
> merged with the right tool instead of just keeping either the repository
> or local props.
Here's my interactive-prop-conflict design. Code forthcoming.
It should make both Mark and Stefan happy.
The only property actions are 'set' and 'delete'. Thus there are only
2 types of prop conflicts:
- two people try to set the same property to different values
- one person sets a prop, another person deletes it
(Both people deleting a prop is a mergeable change, as is two propsets
to the same value.)
In svn 1.4, when a property conflict happens, libsvn_wc just marks the
file conflicted and creates a "foo.c.prej" file that describes the
conflict. (The contents of the file are something like: "Hey, your
local edit sets the property 'foo' to 'bar', but the repository wants
to set 'foo' to 'baz'.")
Proposal to extend our interactive conflict callback for props:
- Invoke conflict callback for *each* property conflict discovered.
This means that the conflict callback might be invoked many times
on the same path -- e.g. once for a text conflict, and N more
times for N property conflicts on the same file.
- svn_wc_conflict_description_t is expanded to describe a property
conflict:
- add new fields, and only set them when we're describing a
prop-conflict:
const char *propname;
svn_string_t *base_propvalue;
svn_string_t *their_propvalue;
svn_string_t *my_propvalue;
- the "action" field is either 'edit' or 'delete'... (and
'their_propvalue' is correspondingly non-NULL or NULL.)
- the "reason" field is either 'edited' or 'deleted'... (and
'my_propvalue) is correspondingly non-NULL or NULL.)
- svn_wc_conflict_result_t is expanded to describe the resolution of
a property conflict:
- add a new field:
svn_string_t *merged_propvalue;
- add new enums:
svn_wc_conflict_result_choose_base_propvalue
svn_wc_conflict_result_choose_their_propvalue
svn_wc_conflict_result_choose_my_propvalue
svn_wc_conflict_result_choose_mergede_propvalue
As one would expect, returning one of these new result-codes tells
libsvn_wc to install one of the three original propvalues, or
to use the new 'merged_propvalue' that the callback is providing.
- returning 'svn_wc_conflict_result_conflicted' tells libsvn_wc
to just mark the file conflicted, create the usual .prej file,
and allow conflict resolution to be postponed for later.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Stefan Küng <to...@gmail.com>.
Ben Collins-Sussman wrote:
> On 9/6/07, Stefan Küng <to...@gmail.com> wrote:
>> Hi,
>>
>> I'm currently implementing the new conflict resolver callback in TSVN.
>> And I'm not sure if I simply don't quite understand the data I get or
>> there's something missing:
>> how do I know whether the conflict is in the file contents or the file
>> properties? Or is the callback not invoked for property conflicts? If it
>> is, shouldn't there be some flag in the svn_wc_conflict_description_t
>> struct indicating whether it's a file or property conflict (or both)?
>>
>
> No, you're not missing anything. The feature isn't finished yet. :-)
>
> At the moment, the conflict-callback is only called on file-contents
> conflicts. On my TO-DO list is:
>
> - call the callback on prop-conflicts
> - call the callback from 'svn switch'
> - call the callback from 'svn merge'
>
> And yes, you're right: we should expand the conflict_description_t to
> indicate text vs. prop conflict.
And please consider not just a boolean for this. The property name would
be very useful: the svn: properties are basically text and could be
merged with the right tool instead of just keeping either the repository
or local props.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Stefan Küng <to...@gmail.com>.
Ben Collins-Sussman wrote:
> On 9/6/07, Stefan Küng <to...@gmail.com> wrote:
>> Hi,
>>
>> I'm currently implementing the new conflict resolver callback in TSVN.
>> And I'm not sure if I simply don't quite understand the data I get or
>> there's something missing:
>> how do I know whether the conflict is in the file contents or the file
>> properties? Or is the callback not invoked for property conflicts? If it
>> is, shouldn't there be some flag in the svn_wc_conflict_description_t
>> struct indicating whether it's a file or property conflict (or both)?
>>
>
> No, you're not missing anything. The feature isn't finished yet. :-)
>
> At the moment, the conflict-callback is only called on file-contents
> conflicts. On my TO-DO list is:
>
> - call the callback on prop-conflicts
> - call the callback from 'svn switch'
> - call the callback from 'svn merge'
>
> And yes, you're right: we should expand the conflict_description_t to
> indicate text vs. prop conflict.
Thanks for the info!
I'll implement the callback then for files only (for now).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: conflict resolver callback question / enhancement request
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 9/6/07, Stefan Küng <to...@gmail.com> wrote:
> Hi,
>
> I'm currently implementing the new conflict resolver callback in TSVN.
> And I'm not sure if I simply don't quite understand the data I get or
> there's something missing:
> how do I know whether the conflict is in the file contents or the file
> properties? Or is the callback not invoked for property conflicts? If it
> is, shouldn't there be some flag in the svn_wc_conflict_description_t
> struct indicating whether it's a file or property conflict (or both)?
>
No, you're not missing anything. The feature isn't finished yet. :-)
At the moment, the conflict-callback is only called on file-contents
conflicts. On my TO-DO list is:
- call the callback on prop-conflicts
- call the callback from 'svn switch'
- call the callback from 'svn merge'
And yes, you're right: we should expand the conflict_description_t to
indicate text vs. prop conflict.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org