I'm not sure where JM is on his articles and I've never used
Clearcase/Clearquest and not familiar with their workflow but I'll comment
on how I use and perceive Jazz Source Control and maybe it'll help. I'm
going to be overly verbose here.

The closest thing you'll find to visualization is by right Clicking a
Repository Workspace>New Flow Diagram... That will start a visualization
editor that is more-so meant for read only (but you can do things like
change flow targets and create new streams... just be aware of the
repercussions of editing your whole stream hierarchy like this. It'd be
easy to quickly make wide-spread changes).

The flow diagram gives you a good idea of who (via Repository Workspaces)
is working on particular streams. The streams themselves can have flow
targets to other streams to make a hierarchy (and this may, or maynot
affect how your build works).

But I think the key difference is that this is a "Flow Diagram" which
gives you an *idea* of how changesets propagate from one stream to another
but that is not necessarily equivalent to a 'revision' graph. Just because
one stream is 'higher' on the hierarchy doesn't mean its configuration was
directed by all the streams below it. Changesets in a stream can be
discarded afterwards, or they can be accepted from work items or searches
(bypassing the flow hierarchy).

So when we're interested in comparing two streams/workspaces or two
configurations of a component, we're actually just interested in seeing
what change sets the left hand side includes/missing compared to the right
hand side. If the Right hand side is higher in the hierarchy, and you flow
all the changes from the left side to right side, you might think of the
right side being a revision built on the left side. Conceptually it will
work and feel right as one stream being built off others but in terms of
baseline and changeset configuration under the covers, they essentially
just share a common history.

Going to the history view, the history view works within a configuration
of a component, but not across configurations of components that that are
different across a hierarchy of streams. If you look at the history of a
component, you see the ordered list of change sets that the configuration
contains. If you look at the history of a file (given a certain component
configuration), you will see a merge graph for that file. You may be able
to infer from the forks in the graph that the branches were made in a
different repository workspace or stream, and somehow come back to be
merged into the configuration.

I hope that potentially answers some questions, or raises new ones.

On Mon, 23 Nov 2009 10:38:01 -0500, gorand
<gorand> wrote:

Coming from the Clearcase(/Clearquest) world, I was wondering why
there was no way to graphically show the relationships between
various streams/workspaces for any given component and/or repository
element (i.e. revision graph -type feature).

In this thread
http://jazz.net/forums/viewtopic.php?p=21359&sid=0f2b6a388e9218d99a234e38bbcbe58e

Jean-Michel mentioned that he was working on a paper that would
describe some of the resons for why history works the way it does,
etc. Is the paper available?

Thanks in advance for your comments.

Goran

One follow-up comment ... if you want the full version graph of a
particular file, you can select the "Show All In Repository" operation
in the History view, and the version tree will be extended to show all
versions in all configurations (streams, workspaces) and change-sets in
the repository.

Cheers,
Geoff

Andrew Hoo wrote:

I'm not sure where JM is on his articles and I've never used
Clearcase/Clearquest and not familiar with their workflow but I'll
comment on how I use and perceive Jazz Source Control and maybe it'll
help. I'm going to be overly verbose here.

The closest thing you'll find to visualization is by right Clicking a
Repository Workspace>New Flow Diagram... That will start a visualization
editor that is more-so meant for read only (but you can do things like
change flow targets and create new streams... just be aware of the
repercussions of editing your whole stream hierarchy like this. It'd be
easy to quickly make wide-spread changes).

The flow diagram gives you a good idea of who (via Repository
Workspaces) is working on particular streams. The streams themselves can
have flow targets to other streams to make a hierarchy (and this may, or
maynot affect how your build works).

But I think the key difference is that this is a "Flow Diagram" which
gives you an *idea* of how changesets propagate from one stream to
another but that is not necessarily equivalent to a 'revision' graph.
Just because one stream is 'higher' on the hierarchy doesn't mean its
configuration was directed by all the streams below it. Changesets in a
stream can be discarded afterwards, or they can be accepted from work
items or searches (bypassing the flow hierarchy).

So when we're interested in comparing two streams/workspaces or two
configurations of a component, we're actually just interested in seeing
what change sets the left hand side includes/missing compared to the
right hand side. If the Right hand side is higher in the hierarchy, and
you flow all the changes from the left side to right side, you might
think of the right side being a revision built on the left side.
Conceptually it will work and feel right as one stream being built off
others but in terms of baseline and changeset configuration under the
covers, they essentially just share a common history.

Going to the history view, the history view works within a configuration
of a component, but not across configurations of components that that
are different across a hierarchy of streams. If you look at the history
of a component, you see the ordered list of change sets that the
configuration contains. If you look at the history of a file (given a
certain component configuration), you will see a merge graph for that
file. You may be able to infer from the forks in the graph that the
branches were made in a different repository workspace or stream, and
somehow come back to be merged into the configuration.

I hope that potentially answers some questions, or raises new ones.

On Mon, 23 Nov 2009 10:38:01 -0500, gorand
gorand@ca.ibm-dot-com.no-spam.invalid> wrote:

Coming from the Clearcase(/Clearquest) world, I was wondering why
there was no way to graphically show the relationships between
various streams/workspaces for any given component and/or repository
element (i.e. revision graph -type feature).

In this thread
http://jazz.net/forums/viewtopic.php?p=21359&sid=0f2b6a388e9218d99a234e38bbcbe58e


Jean-Michel mentioned that he was working on a paper that would
describe some of the resons for why history works the way it does,
etc. Is the paper available?

Thanks in advance for your comments.

Goran

One follow-up comment ... if you want the full version graph of a
particular file, you can select the "Show All In Repository" operation
in the History view, and the version tree will be extended to show all
versions in all configurations (streams, workspaces) and change-sets in
the repository.

Geoff,
I just tried this out in our repo. Very neat! However, I can't find a way to show what streams/workspaces/etc. the lines represent. I can't hover over the "dots" in the graph nor over the line itself. Is there any way to get this information? Otherwise, I am looking at multiple lines, each of which represents (I think) a stream, but don't know *which* streams they represent.

Thanks,
Mike

I don't think there's currently any way to get that information.
I've submitted work item 100643 "In File History view, for each version,
provide way to show list of workspaces/streams that currently select
that version".

Note that although a line represents a single line of descent, it might
have resulted from changes in a variety of streams/workspaces.
Conversely, the changes from a single stream or workspace can take place
over several lines.

Cheers,
Geoff

micjohnson997 wrote:

gmclemmwrote:
One follow-up comment ... if you want the full version graph of a
particular file, you can select the "Show All In
Repository" operation
in the History view, and the version tree will be extended to show
all
versions in all configurations (streams, workspaces) and change-sets
in
the repository.
Geoff,
I just tried this out in our repo. Very neat! However, I can't find
a way to show what streams/workspaces/etc. the lines represent. I
can't hover over the "dots" in the graph nor over the line
itself. Is there any way to get this information? Otherwise, I am
looking at multiple lines, each of which represents (I think) a
stream, but don't know *which* streams they represent.

Thanks,
Mike

I think I need to have a better idea of what your expectations of revision
graph shows and how it's used. Especially if 'important events' are to
relate back to streams so that you can use it to decide which streams to
compare. Feel free to open up an enhancement. But what exactly are you
doing? Maybe there's an alternative work flow in RTC (maybe better or
worse, or just different)

Geoff mentioned the Show All In Repository mode of the history view which
gets you branch/merge history but as he points out, the lines of descent
do not necessarily correlate to any one particular workspace or stream.
Noteably, merges of conflicts are always done in workspaces first (which
is probably not what you want to see) and then either delivered,
replaced-component, or 'cherry picked from work items' into streams. So
when you see a dot representing merge (or any state change), and the lines
to its ancestors, those lines may have no bearing on how that state got to
any streams it happens to currently be in.

As for hovering on the dots to find the streams that the CS is included
in, this is essentially the same issue as Locate Change Set requiring you
to pick a target stream to inspect, instead of just telling you a list.
This feature is often requested. If we address this we'll want to make
sure we get it right because we can easily be dealing with 100s of streams
and 100s of changesets in one history view.

There are two issues with history on a folder. One is that often the
history of a folder is sometimes thought of the history of everything in
the subtree of that folder - and the implementation of that is more
complicated than you would expect. Secondly, if you're just talking about
the history of that particular folder, the only things that happen to
folders are creation/renames/move/delete. Which is still valid history,
but generally doesn't change too much. So the lack of that feature is just
that it hasn't be done - but also it then doesn't lead into confusion with
the 1st issue.

On Mon, 30 Nov 2009 15:52:59 -0500, gorand
<gorand> wrote:

Thanks for your replies.

To pick up on Andrew's comment about comparing two streams: revision
graphs are useful, I think, in understanding which two streams to
select for comparison. Version tree allows you to (easily and
chronologically) see important events (i.e. branch/merge points) for
objects in the repository which then allow you to decide where to
drill down to low-level detail (e.g. linear history view and various
compare functions).

'Locate Change set' feature seems to have been intended for this
purpose but I don't understand why I need to tell it where to go look
for a change set - that's what I'm trying to find out, no?

The Merges column in History view looks interesting but rather
constrained (relative to other SCM systems); could we get
stream/workspace names displayed as well?

Also, why can't one display the history of a folder?

--