You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Garrett Rooney <ro...@electricjellyfish.net> on 2006/07/05 23:02:20 UTC
Merge Tracking Metadata Interface
As I was watching dlr tweak tests on the merge-tracking branch to
expect the presence of a svn:mergeinfo property, I started to wonder
if that's really how we want to show things to the user. Do we want
the fact that merge info has been stored in the working copy to show
up in status output in the same place as we indicate a change to (for
example) svn:ignore? I'm not positive one way or the other, but I
think we should discuss it before Dan spends days tweaking tests.
More important, in my mind, is how these property changes show up in
diffs. I just noticed that when you do a diff after using svnmerge.py
to merge a change the diff output isn't all that friendly. You end up
with the old long-ass line of revision ranges, then the new long-ass
line of revision changes. Do we perhaps want to special case this
property? Showing it as "Added rXXX" or "Removed rXXX"?
I don't really have a well formed opinion here, but I'm leaning
towards "it's ok for it to show up as a propchange in status", and "we
should special case it in diff", but I'm curious what other people
think about this.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Kamesh Jayachandran <ka...@collab.net>.
Got clarified.
Working on similar customization for svn:mergeinfo, got stuck up with
some yet to isolate bug in 'svn_rangelist_diff'
With regards
Kamesh Jayachandran
Eric Gillespie wrote:
> Kamesh Jayachandran <ka...@collab.net> writes:
>
>
>>> We already special-case at least svn:executable in diff.
>>>
>>>
>>>
>> Are you sure?
>>
>
> Certain. Just look at what you pasted:
>
>
>> [kamesh@kamesh ttt]$ svn ps svn:executable '1' test.txt
>> property 'svn:executable' set on 'test.txt'
>> [kamesh@kamesh ttt]$ svn st
>> M test.txt
>> [kamesh@kamesh ttt]$ svn diff
>>
>> Property changes on: test.txt
>> ___________________________________________________________________
>> Name: svn:executable
>> + *
>>
>
> It shows '*', not '1'.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Thu, Jul 06, 2006 at 06:28:22AM -0700, Eric Gillespie wrote:
> Kamesh Jayachandran <ka...@collab.net> writes:
>
> > > We already special-case at least svn:executable in diff.
> > >
> > >
> >
> > Are you sure?
>
> Certain. Just look at what you pasted:
>
> > [kamesh@kamesh ttt]$ svn ps svn:executable '1' test.txt
> > property 'svn:executable' set on 'test.txt'
> > [kamesh@kamesh ttt]$ svn st
> > M test.txt
> > [kamesh@kamesh ttt]$ svn diff
> >
> > Property changes on: test.txt
> > ___________________________________________________________________
> > Name: svn:executable
> > + *
>
> It shows '*', not '1'.
>
Nitpicking, but that substitution is done while fetching the props from
the wc, not by diff itself. Hmm, does that mean that a repos-repos diff
will show the original value? I suspect it does.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Kamesh Jayachandran <ka...@collab.net> writes:
> > We already special-case at least svn:executable in diff.
> >
> >
>
> Are you sure?
Certain. Just look at what you pasted:
> [kamesh@kamesh ttt]$ svn ps svn:executable '1' test.txt
> property 'svn:executable' set on 'test.txt'
> [kamesh@kamesh ttt]$ svn st
> M test.txt
> [kamesh@kamesh ttt]$ svn diff
>
> Property changes on: test.txt
> ___________________________________________________________________
> Name: svn:executable
> + *
It shows '*', not '1'.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Kamesh Jayachandran <ka...@collab.net>.
> +1
>
> We already special-case at least svn:executable in diff.
>
>
Are you sure?
[kamesh@kamesh ttt]$ svn ps svn:executable '1' test.txt
property 'svn:executable' set on 'test.txt'
[kamesh@kamesh ttt]$ svn st
M test.txt
[kamesh@kamesh ttt]$ svn diff
Property changes on: test.txt
___________________________________________________________________
Name: svn:executable
+ *
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Daniel Rall <dl...@collab.net>.
On Fri, 07 Jul 2006, Garrett Rooney wrote:
> On 7/7/06, Madan U Sreenivasan <ma...@collab.net> wrote:
>
> >Manual merges need to be hand-edited... (or maybe we should provide an
> >equivalent of the --record-only option in svnmerge!)
>
> That's what I'm saying, I think it's insane to expect people to hand
> edit it. We will have to provide some sort of command to manage it.
The plan has been to provide the equivalent of 'merge --record-only'
(along with most of the svnmerge.py-like higher level operations) for
as long as there as been a plan. :-P
Re: Merge Tracking Metadata Interface
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/7/06, Madan U Sreenivasan <ma...@collab.net> wrote:
> Manual merges need to be hand-edited... (or maybe we should provide an
> equivalent of the --record-only option in svnmerge!)
That's what I'm saying, I think it's insane to expect people to hand
edit it. We will have to provide some sort of command to manage it.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Fri, 07 Jul 2006 19:33:09 +0530, Garrett Rooney
<ro...@electricjellyfish.net> wrote:
> On 7/7/06, Madan U Sreenivasan <ma...@collab.net> wrote:
>
>> I beg to differ, because of the following reasons
>>
>> 1) diff is supposed to show the difference (both old and new values),
>> and
>> not just a human interpretation of what was merged/reverted. For this
>> kind
>> of reporting, status would be a better place (or better still, the
>> audit,
>> reporting tools that we are planning to develop in phase 2.)
>> 2) The reason we have a string representation for svn:mergeinfo is so
>> that
>> it is hand-editable (It is not just an implementation detail, we expect
>> the users to update svn:mergeinfo to reflect manual merges). Showing
>> interpreted info in diff and showing the original svn:mergeinfo value in
>> propedit will confuse the user.
>
> I think we're kidding ourselves if we think that these properties are
> going to be hand editable for anyone who is not a Subversion
> developer,
Manual merges need to be hand-edited... (or maybe we should provide an
equivalent of the --record-only option in svnmerge!)
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Fri, Jul 07, 2006 at 10:03:09AM -0400, Garrett Rooney wrote:
> I think we're kidding ourselves if we think that these properties are
> going to be hand editable for anyone who is not a Subversion
> developer, and I think that producing useful diff output (i.e. that
> can be consumed by a user) is more important than showing a literal
> diff.
+1. Completely agreed.
I did say before that I would be happy to suppress the mergeinfo output
in diff, but I think that producing a human-readable output is probably
even better.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/7/06, Madan U Sreenivasan <ma...@collab.net> wrote:
> I beg to differ, because of the following reasons
>
> 1) diff is supposed to show the difference (both old and new values), and
> not just a human interpretation of what was merged/reverted. For this kind
> of reporting, status would be a better place (or better still, the audit,
> reporting tools that we are planning to develop in phase 2.)
> 2) The reason we have a string representation for svn:mergeinfo is so that
> it is hand-editable (It is not just an implementation detail, we expect
> the users to update svn:mergeinfo to reflect manual merges). Showing
> interpreted info in diff and showing the original svn:mergeinfo value in
> propedit will confuse the user.
I think we're kidding ourselves if we think that these properties are
going to be hand editable for anyone who is not a Subversion
developer, and I think that producing useful diff output (i.e. that
can be consumed by a user) is more important than showing a literal
diff. It's not like the literal diff is actually being consumed by
any external tools (a-la patch) anyway. If we want a literal
transcription of what changed, we need a more robust diff format
anyway.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Kamesh Jayachandran <ka...@collab.net>.
Madan U Sreenivasan wrote:
> On Fri, 07 Jul 2006 14:12:21 +0530, Kamesh Jayachandran
> <ka...@collab.net> wrote:
>
>> Madan U Sreenivasan wrote:
> [snip]
>>> 1) diff is supposed to show the difference (both old and new
>>> values), and not just a human interpretation of what was
>>> merged/reverted. For this kind of reporting, status would be a
>>> better place (or better still, the audit, reporting tools that we
>>> are planning to develop in phase
>> IIRC prop diff output is not meant for any tools and just for human
>> eyes.
>> I feel the pretty output of 'svn:mergeinfo' prop would be more human
>> friendly than current svn diff output
>> See how bad it is
> [snip]
>> Quick question:
>> Can you from the above output can you see what got changed? (Scroll
>> down for answers)
>> Things could be even worser.
>
> Same applies even for multiple changes across 100 different files in
> the codebase. The complexity of the user changes, I beleive are not
> sufficient to change the beahvior of the 'diff' functionality.
>
You can consider this kind of 'special binary diff'. More on that
follows below.
For big set of file changes, I can always pipe to readymade
lsdiff/filterdiff, rather than writing your own awk/perl magic to parse
this mergeinfo differences.
>>> 2) The reason we have a string representation for svn:mergeinfo is
>>> so that it is hand-editable (It is not just an implementation
>>> detail, we expect the users to update svn:mergeinfo to reflect
>>> manual merges). Showing interpreted info in diff and showing the
>>> original svn:mergeinfo value in propedit will confuse the user.
>> If I understand you 'User should never be hidden the actual changes',
>> we show it when he does a 'svn propedit/pg/pl -v'.
>> If I understand you in favour of exposing the internals so that it
>> would make him to knowledgable to tweak this property to block merges
>> and such. I don't think it outweighs the crisp info one would be
>> willing to see.
>
> Nah. The main point is, It would be confusing to show a particular
> diff, while actually storing something else in the backend(especially
> when the user is allowed to hand-edit it).
>
If he hand edit his subsequent diff should show the corresponding pretty
output.
I think this can be considered as a special case of diff like 'binary
diff for PDF/gif'. i.e Each file/entity can have its own way of knowing
what got changed, not all need to be unified diff as it is currently.
Only thing is that this 'svn:mergeinfo' pretty diff is builtin unlike
--diff-cmd=some_third_party_tool.
I don't think unified diff is the useful format for 'svn:mergeinfo' prop
diffs.
I believe diff is just diff. The format is a matter of convenience, we
normally choose 'unified diff' as it is widely accepted by many tools.
As prop diffs produced by 'svn diff' are not used by external tools
atleast to my knowledge, I don't think sticking to 'unified diff'.
Only entity who can consume at least to my knowledge is human being who
is more pleased with the following output rather than the one I have
shown in earlier email.(May be someone would have scripted it to parse
it, just to keep those scripting, I don't prefer regular users to swim
the big matrix of path Vs rev list)
<snip>
Property changes on: trunk
___________________________________________________________________
svn:mergeinfo
Reverted /branches/b1:r154
Merged /branches/blah:r67:87
</snip>
Note: I never used any binary diffs in the past just heard of few for
Word doc exists.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Fri, 07 Jul 2006 14:12:21 +0530, Kamesh Jayachandran
<ka...@collab.net> wrote:
> Madan U Sreenivasan wrote:
[snip]
>> 1) diff is supposed to show the difference (both old and new values),
>> and not just a human interpretation of what was merged/reverted. For
>> this kind of reporting, status would be a better place (or better
>> still, the audit, reporting tools that we are planning to develop in
>> phase
> IIRC prop diff output is not meant for any tools and just for human eyes.
> I feel the pretty output of 'svn:mergeinfo' prop would be more human
> friendly than current svn diff output
> See how bad it is
[snip]
> Quick question:
> Can you from the above output can you see what got changed? (Scroll down
> for answers)
> Things could be even worser.
Same applies even for multiple changes across 100 different files in the
codebase. The complexity of the user changes, I beleive are not sufficient
to change the beahvior of the 'diff' functionality.
>> 2) The reason we have a string representation for svn:mergeinfo is so
>> that it is hand-editable (It is not just an implementation detail, we
>> expect the users to update svn:mergeinfo to reflect manual merges).
>> Showing interpreted info in diff and showing the original svn:mergeinfo
>> value in propedit will confuse the user.
> If I understand you 'User should never be hidden the actual changes', we
> show it when he does a 'svn propedit/pg/pl -v'.
> If I understand you in favour of exposing the internals so that it would
> make him to knowledgable to tweak this property to block merges and
> such. I don't think it outweighs the crisp info one would be willing to
> see.
Nah. The main point is, It would be confusing to show a particular diff,
while actually storing something else in the backend(especially when the
user is allowed to hand-edit it).
>> Well, you may say svn:executable does show a "*" when the user said
>> "1". Well, "*" is what is actually stored in the property. So, the user
>> is not gonna be surprised about what he sees in the diff and what he
>> sees when he propedits.
> He would not be surprised unless he knows subversion internals or did
> 'propedit' atleast once(Me included it was a info for me yesterday, but
> it does not matter for not knowing this as long as I know what for
> 'svn:executable' is)
We are talking the same thing here.
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by David Glasser <gl...@mit.edu>.
Kamesh Jayachandran <kamesh <at> collab.net> writes:
> Quick question:
> Can you from the above output can you see what got changed? (Scroll down
> for answers)
Arguably, the lesson to be learned from that is just that property changes
should actually be shown as (some sort of) diff. (SVK does this, which makes
diffs on its similar svk:merge property vaguely intelligible.)
--dave
glasser@mit.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Kamesh Jayachandran <ka...@collab.net>.
Madan U Sreenivasan wrote:
> On Thu, 06 Jul 2006 14:09:53 +0530, Malcolm Rowe
> <ma...@farside.org.uk> wrote:
>
>> On Wed, Jul 05, 2006 at 04:32:25PM -0700, Eric Gillespie wrote:
>>> "Garrett Rooney" <ro...@electricjellyfish.net> writes:
>>>
>>> > line of revision changes. Do we perhaps want to special case this
>>> > property? Showing it as "Added rXXX" or "Removed rXXX"?
>>> >
>>> > I don't really have a well formed opinion here, but I'm leaning
>>> > towards "it's ok for it to show up as a propchange in status", and
>>> "we
>>> > should special case it in diff", but I'm curious what other people
>>> > think about this.
>>>
>>> +1
>>>
>>> We already special-case at least svn:executable in diff.
>>>
>>
>> Really? I don't see that.
>>
>> Anyway, +1 from me also to inihibiting the output of mergeinfo-related
>> properties in libsvn_client's diffs. It's an implementation detail,
>> and I don't think it's ever useful to expose it in the default diff
>> output.
>
> I beg to differ, because of the following reasons
>
> 1) diff is supposed to show the difference (both old and new values),
> and not just a human interpretation of what was merged/reverted. For
> this kind of reporting, status would be a better place (or better
> still, the audit, reporting tools that we are planning to develop in
> phase
IIRC prop diff output is not meant for any tools and just for human eyes.
I feel the pretty output of 'svn:mergeinfo' prop would be more human
friendly than current svn diff output
See how bad it is
Property changes on: .
___________________________________________________________________
Name: svn:mergeinfo
-/branches/b1:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b2:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b3:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b4:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b5:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b6:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b7:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b8:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b9:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b10:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b11:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b12:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b13:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b14:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
+/branches/b1:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b2:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b3:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b4:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b5:22, 31-46, 48-61, 68-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b6:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b7:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b8:22, 31-46, 48-61, 65-76, 79-92, 105-112, 115-118, 120-125,
135-140
/branches/b9:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b10:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b11:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b12:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b13:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
/branches/b14:22, 31-46, 48-61, 65-76, 79-92, 96-102, 105-112, 115-118,
120-125
Quick question:
Can you from the above output can you see what got changed? (Scroll down
for answers)
Things could be even worser.
> 2) The reason we have a string representation for svn:mergeinfo is so
> that it is hand-editable (It is not just an implementation detail, we
> expect the users to update svn:mergeinfo to reflect manual merges).
> Showing interpreted info in diff and showing the original
> svn:mergeinfo value in propedit will confuse the user.
If I understand you 'User should never be hidden the actual changes', we
show it when he does a 'svn propedit/pg/pl -v'.
If I understand you in favour of exposing the internals so that it would
make him to knowledgable to tweak this property to block merges and
such. I don't think it outweighs the crisp info one would be willing to see.
> Well, you may say svn:executable does show a "*" when the user said
> "1". Well, "*" is what is actually stored in the property. So, the
> user is not gonna be surprised about what he sees in the diff and what
> he sees when he propedits.
He would not be surprised unless he knows subversion internals or did
'propedit' atleast once(Me included it was a info for me yesterday, but
it does not matter for not knowing this as long as I know what for
'svn:executable' is)
With regards
Kamesh Jayachandran
Answer to quick question Revert of /branches/b8:96-102 and merge of
135-140, revert of /branches/b5:65-67.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Fri, 07 Jul 2006 11:49:53 +0530, Madan U Sreenivasan <ma...@collab.net>
wrote:
[snip]
> I agree with Garrett though that in 'status', we could show the
> svn:mergeinfo property changes as related to the file instead of adding
> it to the property changes listing that preceeds the file changes.
Pl. ignore that para... I was drunk when I wrote that ;)
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Thu, 06 Jul 2006 14:09:53 +0530, Malcolm Rowe
<ma...@farside.org.uk> wrote:
> On Wed, Jul 05, 2006 at 04:32:25PM -0700, Eric Gillespie wrote:
>> "Garrett Rooney" <ro...@electricjellyfish.net> writes:
>>
>> > line of revision changes. Do we perhaps want to special case this
>> > property? Showing it as "Added rXXX" or "Removed rXXX"?
>> >
>> > I don't really have a well formed opinion here, but I'm leaning
>> > towards "it's ok for it to show up as a propchange in status", and "we
>> > should special case it in diff", but I'm curious what other people
>> > think about this.
>>
>> +1
>>
>> We already special-case at least svn:executable in diff.
>>
>
> Really? I don't see that.
>
> Anyway, +1 from me also to inihibiting the output of mergeinfo-related
> properties in libsvn_client's diffs. It's an implementation detail,
> and I don't think it's ever useful to expose it in the default diff
> output.
I beg to differ, because of the following reasons
1) diff is supposed to show the difference (both old and new values), and
not just a human interpretation of what was merged/reverted. For this kind
of reporting, status would be a better place (or better still, the audit,
reporting tools that we are planning to develop in phase 2.)
2) The reason we have a string representation for svn:mergeinfo is so that
it is hand-editable (It is not just an implementation detail, we expect
the users to update svn:mergeinfo to reflect manual merges). Showing
interpreted info in diff and showing the original svn:mergeinfo value in
propedit will confuse the user.
Well, you may say svn:executable does show a "*" when the user said "1".
Well, "*" is what is actually stored in the property. So, the user is not
gonna be surprised about what he sees in the diff and what he sees when he
propedits.
I agree with Garrett though that in 'status', we could show the
svn:mergeinfo property changes as related to the file instead of adding it
to the property changes listing that preceeds the file changes.
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Wed, Jul 05, 2006 at 04:32:25PM -0700, Eric Gillespie wrote:
> "Garrett Rooney" <ro...@electricjellyfish.net> writes:
>
> > line of revision changes. Do we perhaps want to special case this
> > property? Showing it as "Added rXXX" or "Removed rXXX"?
> >
> > I don't really have a well formed opinion here, but I'm leaning
> > towards "it's ok for it to show up as a propchange in status", and "we
> > should special case it in diff", but I'm curious what other people
> > think about this.
>
> +1
>
> We already special-case at least svn:executable in diff.
>
Really? I don't see that.
Anyway, +1 from me also to inihibiting the output of mergeinfo-related
properties in libsvn_client's diffs. It's an implementation detail,
and I don't think it's ever useful to expose it in the default diff
output.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Garrett Rooney" <ro...@electricjellyfish.net> writes:
> line of revision changes. Do we perhaps want to special case this
> property? Showing it as "Added rXXX" or "Removed rXXX"?
>
> I don't really have a well formed opinion here, but I'm leaning
> towards "it's ok for it to show up as a propchange in status", and "we
> should special case it in diff", but I'm curious what other people
> think about this.
+1
We already special-case at least svn:executable in diff.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/6/06, Kamesh Jayachandran <ka...@collab.net> wrote:
> Garrett Rooney wrote:
> > As I was watching dlr tweak tests on the merge-tracking branch to
> > expect the presence of a svn:mergeinfo property, I started to wonder
> > if that's really how we want to show things to the user. Do we want
> > the fact that merge info has been stored in the working copy to show
> > up in status output in the same place as we indicate a change to (for
> > example) svn:ignore? I'm not positive one way or the other, but I
> > think we should discuss it before Dan spends days tweaking tests.
> Are you sure about svn:ignore ?
> [kamesh@kamesh ttt]$ svn ps svn:ignore '1' trunk
> property 'svn:ignore' set on 'trunk'
> [kamesh@kamesh ttt]$ svn st
> M trunk
> [kamesh@kamesh ttt]$ svn diff
>
> Property changes on: trunk
> ___________________________________________________________________
> Name: svn:ignore
> + 1
What I meant when I referred to svn:ignore was that if we want to make
it clear that merge info was being tracked, it might be worthwhile
having that show up separately from other directory property changes,
like svn:ignore, at least in status output. Sure, the diff shows you
that it's an ignore change, but the status just shows up like any
other propchange.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Metadata Interface
Posted by Kamesh Jayachandran <ka...@collab.net>.
Garrett Rooney wrote:
> As I was watching dlr tweak tests on the merge-tracking branch to
> expect the presence of a svn:mergeinfo property, I started to wonder
> if that's really how we want to show things to the user. Do we want
> the fact that merge info has been stored in the working copy to show
> up in status output in the same place as we indicate a change to (for
> example) svn:ignore? I'm not positive one way or the other, but I
> think we should discuss it before Dan spends days tweaking tests.
Are you sure about svn:ignore ?
[kamesh@kamesh ttt]$ svn ps svn:ignore '1' trunk
property 'svn:ignore' set on 'trunk'
[kamesh@kamesh ttt]$ svn st
M trunk
[kamesh@kamesh ttt]$ svn diff
Property changes on: trunk
___________________________________________________________________
Name: svn:ignore
+ 1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org