Re: SV: Revision graph rewrite

Stefan.Fuhrmann@etas.de wrote:

> However, there is a basic problem with all those approaches:
> Different projects may use different repository layouts, branch
> and tag policies. Most importantly, they may also use entirely
> different naming convention. Example: a company may use SVN for
> document management and call their trunk "draft" and their tags
> "QAx". But I am already thinking about a solution here.
>
> An smaller issue related to this is that many projects don't tag
> from the /trunk but from (stabilization / maintenance) branches.
> Hence, separating them will obscure the "meaning" or "content"
> of the individual tags. Once way to relax that issue would be
> placing "non-tagging" branches (i.e. feature or developer branches)
> to the right while all "tagging" onces are put to the left.

Yes, TSVN and Subversion are just two examples here. We don't tag from
trunk but from branches.

I know you've got some great ideas here. All I'm asking is that you
leave one setting where *all* nodes are shown, without trying to reduce
them. Otherwise we will always get reports about missing nodes.

>
> > Now the revgraph creates good layout (imho) for graphs showing tags, but
> > less good for complicated branching or copying.
>
> It will get *much* harder to layout when merging is shown as
> well.

To show the merging info, we need another Subversion API first. Only if
we can get the Subversion devs to implement that, *then* we can talk
about showing merge info in a graph (doesn't have to be the revision
graph, could be a separate one).

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org