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

Re: Revision graph hide all tags option

From: Simon Large <simon.tortoisesvn_at_gmail.com>
Date: Mon, 30 May 2011 16:34:10 +0100

On 30 May 2011 14:04, Fuhrmann Stefan (ETAS/ESA1)
<Stefan.Fuhrmann_at_etas.com> wrote:
> Simon Large wrote:
>> On 24 May 2011 21:44, Simon Large <simon.tortoisesvn_at_gmail.com> wrote:
>>> On 24 May 2011 11:19, Fuhrmann Stefan (ETAS/ESA1)
>>> <Stefan.Fuhrmann_at_etas.com> wrote:
>>>> Simon Large wrote:
>>>>> On 22 May 2011 07:48, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>>>>>> On 22.05.2011 00:31, Simon Large wrote:
>>>>>>> Hi Stefan(s),
>>>>>>>
>>>>>>> What how does the "hide all tags" option work? If I show the graph
>>>>>>> for TSVN trunk and hide all tags I get left with trunk and 1.6.x.
>>>>>>> Everything else disappears, including branches which were made
>>>>>>> directly from trunk.
>>>>>>
>>>>>> It tries to hide all nodes that are tags, i.e. have /tags/ in their
>>>>>> urls. But as you can see, the guessing isn't perfect.
>>>>>
>>>>> That has got to be a bug. The hard part is working out what is
>>>>> linked to what to generate the tree in the first place, and that
>>>>> seems to work well. Once that mapping is generated it looks as if it
>>>>> should be easy to handle hiding tags consistently at least. I can't
>>>>> see why 1.6.x remains and 1.5.x doesn't. They are both simple stacks of tags, the only difference being that 1.5.x was deleted at the end.
>>>>>
>>>>> Also, hiding deleted branches and tags seems broken. I would expect
>>>>> it to hide the 1.5.x branch but it doesn't. In fact 'Hide tags' does
>>>>> a better job of hiding deleted branches and tags, at least on TSVN trunk.
>>>>
>>>> Hi Simon,
>>>>
>>>> I running r21193 here and it shows the expected graphs for
>>>> $TSVN/trunk.
>>>>
>>>> "hide deleted branches" will only remove those parts that are not the
>>>> copy source of some other part, e.g. a tag. Even "show tags at copy
>>>> source" will not change that. Otherwise, you would not see the tags.
>>>>
>>>> Hiding tags alone produces an 88 nodes graph showing all the obsolete
>>>> branches plus a few tags that we created branches from.
>>>>
>>>> If tags and deleted branches are hidden, you should only see 4 nodes:
>>>> /trunk creation, /trunk head, 1.6.x branch creation and its source
>>>> revision. You may add further nodes by showing HEADs, WC revision
>>>> etc.
>>>
>>> OK, what I see here agrees with your description. I had Fold Tags and
>>> Hide Deleted Branches selected first, then selected Hide tags. The
>>> source of confusion is that the deleted branches are not hidden
>>> initially because the tags taken from them have not been deleted. Once
>>> the tags are hidden those branches all disappear instantly as well.
>>>
>>> I can understand the logic now, but I'm not sure I understand the use
>>> cases.
>
> The revision graph filtering has not been designed with
> specific use-cases in mind. Instead, it attempts a general
> classification of all nodes and allows for hiding certain
> classes of nodes or to otherwise simplify / reduce the graph.
>
> Not all combinations may be useful and it may take more
> than one step to get from one useful selection to another
> (with the intermediate steps being only marginally useful).
>
> So far, it has been about providing maximum flexibility as
> it may be hard to predict what users may want to see and
> what should be hidden _under all circumstances_.
>
>>> If I choose to hide a deleted branch, why would I want to see
>>> the tags of that branch? I would want to see other copies, but a tag
>>> is (normally) just a snapshot of that branch.
>
> The reasoning behind the current behavior is as follows.
> Surviving copies of deleted paths remain visible including
> all their history. Tags are not given a special treatment
> here.
>
> While I understand you POV, others might want to see
> e.g. tags from expired (deleted) maintenance branches
> but still be able to eliminate all the closed, ephemeral
> development branches.
>
>>> That special status is
>>> already acknowledged in the Fold Tags option.
>
> Side note: The classification of a node as being part of
> trunk, some branch, tag or neither is not perfect - just
> a user-defined pattern match. We should try not to rely
> too heavily on that classification scheme.
>
>>> I would expect to hide a
>>> deleted branch whose only copies are tags, and where that branch was a
>>> copy source for a non-tag I would expect to see the minimum nodes on
>>> the deleted branch required to show the ancestry of the non-deleted
>>> copy.
>>>
>>> Thoughts?
>
> After giving that some more thought, I'd like propose the
> following: Since folded tags are reduced to mere decorations /
> properties of the respective source node, "hiding deleted
> branches" we also remove deleted nodes that have no
> copy target except folded tags.
>
> Technically, this is a simple change as the "deletion" code
> will then be executed simply after the tag folding instead
> of before the latter.
>
>> 1.7 release is getting closer so I will just document it the way it already is.
>
> Since there is a considerable backlog of SVN core work
> that I need to see to and I'm in the process of moving,
> I cannot promise anything wrt. to changing the code.

Understood. How about we leave it as is for 1.7 and consider changing
it for 1.8 (or whatever new numbering scheme we ended up with for
after the 1.7 release).

Simon

-- 
:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2753211
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-05-30 17:34:13 CEST

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

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