Abstract:

Computer method and apparatus managing software configuration revisions. A
repository holds one or more assets. For each asset, the repository holds
respective revisions of the asset. A revision manager tracks changes of
state of assets of the repository. Each change of state of a given asset
results in a respective revision of the given asset. The revision manager
provides a project view illustrating for a set of assets (i) changes of
state of assets of the set, (ii) resulting revisions of the assets and
(iii) any relationships between the resulting revisions. In this way,
i.e., via the project view, the present invention revision manager
enables users to manage assets and revisions. The revision manager
renders the project view in one mode illustrating changes made to the
assets (state changes) in order of time, and in another mode illustrating
changes made to the assets (state changes) in order of sequence of
revisions. The revision manager may render the project view effectively
overlaid or otherwise combined with project planning and scheduling
information. The revision manager employs a visual grammar in providing
and generating the project view. The visual grammar employs: lines to
indicate branches, a certain polygon to represent tags, a shaded or
filled circles to represent commit points, and dashed lines to show where
assets are copied from one state to another, merging of changes from one
branch to another, and deletion/creation of branches and assets.

Claims:

1. Computer apparatus for managing engineered product revisions,
comprising:a repository holding one or more assets, for each asset the
repository holding respective revisions of the asset, different assets
forming different engineered products; anda revision manager tracking
changes of state made to assets of the repository, each change of state
made to a given asset resulting in a respective revision of the given
asset, the revision manager enabling users to manage assets and revisions
by providing to users a project view illustrating for a set of assets (i)
changes of state of assets of the set, (ii) resulting revisions of the
assets and (iii) any relationships between the resulting revisions.

2. The apparatus of claim 1, wherein the revision manager renders the
project view in one mode and another mode, the one mode illustrating
changes made to the assets in order of time, andthe another mode
illustrating changes made to the assets in order of sequence of
revisions.

3. The apparatus of claim 1, wherein the project view includes any one or
combination of:branches representing a set of assets;tags representing
state of an asset or set of assets; andcommit points indicating
respective changes of state of one or more assets;copy paths indicating
one or more assets copied from one branch to another; anda head indicator
providing a handle for a latest state of one or more assets.

4. The apparatus of claim 3, wherein the project view further includes any
of:performance indicators corresponding to respective changes of state of
assets;metric change indicators indicating change in respective metric
utilized by performance indicators; anddisplay of annotations by users.

5. The apparatus as claimed in claim 3 wherein the project view further
enables a user to copy or effect a group of assets.

6. The apparatus of claim 3, wherein the revision manager employs a visual
grammar in providing the project view, the visual grammar using any
of:labeled lines to indicate branches,a certain polygon to represent
tags,certain icons for indicating working copy of an asset,squares for
indicating head handles,arrows to indicate changes in performance
metrics,other icons for indicating annotations,dashed lines to indicate
copy paths,colored blocks for performance indicators, anda shaded circle
to represent commit points.

7. The apparatus of claim 3, wherein the project view further includes a
working copy indicator for indicating an asset is currently checked out
of the repository and for indicating there exists a working copy of the
asset.

8. The apparatus as claimed in claim 1 where the revision manager renders
the project view, combined with project planning information, including
effectively overlaying the illustrated set of assets with the project
planning information.

9. A computer implemented method for managing engineered product revisions
comprising the steps of:holding one or more assets in a repository, for
each asset, holding respective revisions of the asset in the repository,
different assets forming different engineered products;tracking changes
of state made to assets of the repository, each change of state made to a
given asset resulting in a respective revision of the given asset;
andgenerating a project view illustrating for a set of assets (i) changes
of state of assets of the set, (ii) resulting revisions of the assets and
(iii) any relationships between the resulting revisions, the project view
assisting users with managing assets and revisions stored to and copied
from the repository.

10. The method as claimed in claim 9 further comprising rendering the
project view in one mode illustrating changes made to the assets in time
order, andrendering the project view in another mode illustrating changes
made to the assets in order of sequence of revisions.

11. The method as claimed in claim 9 wherein the project view includes any
one or combination of:branches representing a set of assets;tags
representing state of an asset or set of assets;commit points indicating
respective changes of state of one or more assets;copy paths indicating
one or more assets copied from one branch to another; anda head indicator
providing a handle for a latest state of one or more assets.

12. The method as claimed in claim 11 wherein the project view further
includes any of:performance indicators corresponding to respective
changes of state of assets;metric change indicators indicating change in
respective metric utilized by performance indicators; andindications of
annotations by users.

13. A method as claimed in claim 11, wherein the project view further
includes a working copy indicator for indicating an asset is currently
checked out of the repository and for indicating there exists a working
copy of the asset.

14. The method as claimed in claim 11 wherein the project view further
enables a user to copy or effect a group of assets.

15. A method as claimed in claim 11, further comprising utilizing a visual
grammar in generating the project view, the visual grammar using any
of:labeled lines to indicate branches,a certain polygon to represent
tags,certain icons for indicating working copy of an asset,squares for
indicating head handles,arrows to indicate changes in performance
metrics,other icons for indicating annotations,dashed lines to indicate
copy paths,colored blocks for performance indicators, anda shaded circle
to represent commit points.

16. A method as claimed in claim 9 wherein the step of generating includes
displaying project planning information relative to the project view,
including effectively combining the project planning information and the
project view in a layering fashion.

17. An engineered product revision management system comprising:repository
means for holding one or more assets, for each asset the repository means
holding respective revisions of the asset, different assets forming
different engineered products;means for tracking changes of state of
assets of the repository means, each change of state of an asset
resulting in a respective revision of the asset; andproject viewing means
for illustrating to users for a set of assets (i) changes of state of
assets of the set, (ii) resulting revisions of the assets and (iii) any
relationships between the resulting revisions, the project viewing means
enabling users to effectively manage assets and revisions of the
repository means.

18. A system as claimed in claim 17 wherein the project viewing means in
one mode illustrates changes to the assets in order of time and in
another mode illustrates changes to the assets in order of sequence of
revisions.

19. A system as claimed in claim 17 wherein the project viewing means
employs any one or combination of:branches representing a set of
assets;tags representing a state of an asset or set of assets; andcommit
points indicating respective changes of state of one or more assets;copy
paths indicating one or more assets copied from one branch to another;a
head indicator providing a handle for a latest state of one or more
assets;performance indicators corresponding to respective changes of
state of assets;metric change indicators indicating change in respective
metric utilized by performance indicators; andtext rendering of
annotations by users.

20. A system as claimed in claim 19 wherein the project viewing means
employs a visual grammar having any of:lines to indicate branches,a
certain polygon to represent tags,certain icons for indicating working
copy of an asset,squares for indicating head handles,arrows to indicate
changes in performance metrics,other icons for indicating
annotations,dashed lines to indicate copy paths,colored blocks for
performance indicators, anda shaded circle to represent commit points.

21. A system as claimed in claim 17 wherein the project viewing means
further employs a working copy indicator for indicating when an asset is
currently checked out of the repository means and for indicating
existence of a working copy of the asset.

22. A system as claimed in claim 17 wherein the project reviewing means
illustrates the set of assets and project planning information in a
combined manner with respect to each other.

23. A computer program product comprising:a computer readable medium
having a computer readable program,wherein the computer readable program
when executed on a computer causes a computer to:hold one or more assets
in a repository, including for each asset holding respective revisions of
the asset in the repository, different assets forming different
engineered products;track state changes of assets of the repository, each
state change of a given asset resulting in a respective revision of the
given asset; andgenerate a project view illustrating to users, for a set
of assets, (i) state changes of assets of the set, (ii) resulting
revisions of the assets and (iii) any relationships between the resulting
revisions, the project view having one mode illustrating state changes of
the assets in time order and another mode illustrating state changes of
assets in order of sequence of revisions.

24. Computer apparatus for rendering views in an engineering product
system, comprising:a repository holding one or more assets, for each
asset the repository holding respective revisions of the asset, different
assets forming different engineered products; andone or more working
modules configured to respectively change state of the repository; anda
view generation assembly coupled to the one or more working modules and
rendering at least one view of assets and revisions associated with the
repository, the view generation assembly including a visual grammar
applied to the at least one view and utilizing any one or combination
of:labeled lines to indicate branches,a certain polygon to represent
tags,certain icons for indicating working copy of an asset,squares for
indicating head handles,arrows to indicate changes in performance
metrics,other icons for indicating annotations,dashed lines to indicate
copy paths,colored blocks for performance indicators, anda shaded circle
to represent commit points.

26. Computer apparatus as claimed in claim 24 wherein the at least one
view includes any of:a project view illustrating for a set of assets (i)
changes of state of assets of the set, (ii) resulting revisions of the
assets and (iii) any relationships between the resulting revisions;a
working copy view;a file history view; anda repository per-asset timeline
view.

27. Computer apparatus as claimed in claim 24 wherein the one or more
working modules includes a revision manager.

28. A computer method for rendering views in an engineering product system
comprising:accessing a repository holding one or more assets, for each
asset the repository holding respective revisions of the asset, different
assets forming different engineered products;employing a visual grammar,
rendering at least one view of assets and revisions associated with the
repository, the visual grammar having any one or combination of:labeled
lines to indicate branches,a certain polygon to represent tags,certain
icons for indicating working copy of an asset,squares for indicating head
handles,arrows to indicate changes in performance metrics,other icons for
indicating annotations,dashed lines to indicate copy paths,colored blocks
for performance indicators, anda filled circle to represent a commit
point.

Description:

RELATED APPLICATIONS

[0001]This application claims the benefit of U.S. Provisional Application
No. 60/994,884, filed on Sep. 21, 2007. The entire teachings of the above
application are incorporated herein by reference.

BACKGROUND OF THE INVENTION

[0002]Engineering is often a collaborative effort. For example, a software
development project requires a team of designers, developers, testers,
and management. Other engineering projects have similar teams of project
members. Tools for supporting and managing the team include integrated
development environments for individual activities as well as
collaborative tools for communicating about and/or sharing data.

[0003]Attempts have been made to codify and/or standardize engineering
processes. Examples in software development include the Unified Modeling
Language (UML) and other visual modeling languages. Such visual modeling
languages have formal syntax and symantics for communicating a model or
conceptualization. In general, at the modeling level a "problem" is posed
in terms of a customer's needs and requirements and may be referred to as
the business problem system. The software designer develops a "solution"
software product and/or services that address the problem. The visual
modeling language syntax enables software designers to express (specify
and document) the subject problems and solutions in a standardized
manner, while the symantics enable knowledge about the subject problem
system to be captured and leveraged during the problem solving phase. As
such, the visual modeling language enables the sharing of information
(including prior solution portions) and extension (without
reimplementation) of core object oriented concepts (analysis and design)
during the iterative problem-solving process for designing software
products.

[0004]Attempts have been made to formalize the capture of artifacts used
to create engineered products, whether the products are
electro-mechanical systems or software applications. In many engineering
environments, these systems are referred to as product data management
(PDM) systems. In software development, these are often referred to as
revision (or version) management systems. Typically these systems serve
as a vault or storage system that captures changes to a product design
over time.

[0005]Most revision management systems include the notions of a repository
and a working copy. The repository is the vault in which all changes are
recorded. The working copy is a snapshot of a specific state in time,
copied to a work space in which an engineer can work on it. Typically a
working (workspace) copy of a file (or asset in general) from the storage
is shown with changes relative to the repository (stored) copy but not
vice versa. "TortoiseSVN", an open source engineering tool, is an
example.

SUMMARY OF THE INVENTION

[0006]The present invention addresses the disadvantages and concerns of
the prior art. In particular the present invention provides a revision
manager that produces a project screen view of assets. The project screen
view shows branches, tags, a trunk and performance indicators of assets.
Each branch represents a respective hierarchy or set of assets. Each tag
represents a hierarchy or set of assets at a specific state. The
performance indicators correspond to tagged states of assets.

[0007]Branches are used to manage development efforts. For example a
branch may be created for each user (team member), or a branch may be
created for each design variant, or a branch may be created for each
product release. The branch may be implemented as a file system
directory. A visual grammar is employed in the project screen view where
performance indicators are color coded and the elements (branches, tags,
performance indicators, commit points) have different respective
geometric shapes or symbols. Performance indicators are tracked within
the revision management system but are displayed in some embodiments only
at critical points such as tags.

[0008]In one embodiment, the revision manager tracks changes of state made
to assets held in a repository. For each change in state of a given
asset, there is a respective resulting revision (version) of the given
asset. The revision manager provides a project view illustrating for a
set of assets (i) changes of state of assets in the set, (ii) the
resulting revisions and (iii) relationships between the resulting
revisions.

[0009]The revision manager renders the project view in at least two modes,
namely sequential mode and temporal mode. In sequential mode, the changes
made to the set of assets are illustrated in order of sequence of
corresponding revisions. In temporal mode, the project view illustrates
the changes made to the set of assets in time order.

[0010]Further the project view includes a working copy indicator for
indicating that an asset is currently checked out of the repository and
thus that there exists a working copy of the asset. The working copy
indicator is a handle (i.e., link or hyperlink) to the working copy of
the asset. Accordingly from the project view, via the working copy
indicator, one is able to access the working copy of the asset as
heretofore unachieved by the prior art.

[0011]In another feature of the invention project view, there is
effectively displayed an overlay of project planning and/or scheduling
information from other applications. The combined information provides an
integrated view of a project plan with actual (current) asset states
(rather than reported asset state changes which often in the prior art
contain errors).

BRIEF DESCRIPTION OF THE DRAWINGS

[0012]The foregoing will be apparent from the following more particular
description of example embodiments of the invention, as illustrated in
the accompanying drawings in which like reference characters refer to the
same parts throughout the different views. The drawings are not
necessarily to scale, emphasis instead being placed upon illustrating
embodiments of the present invention.

[0013]FIG. 1 is a schematic view of an engineered product management
system of the present invention.

[0014]FIG. 2A is a schematic view of a project screen view of the
engineered product management system of FIG. 1 embodying the present
invention.

[0017]FIG. 3 is a schematic view of a computer network environment in
which embodiments of the present invention are implemented.

[0018]FIG. 4 is a block diagram of a node in the computer network of FIG.
3.

[0019]FIG. 5 is a flow diagram of a revision manager according to the
present invention, in the engineered product management system of FIG. 1.

DETAILED DESCRIPTION OF THE INVENTION

[0020]A description of example embodiments of the invention follows.

[0021]Illustrated in FIG. 1 is an engineering product management system 11
embodying the present invention. One example is a software configuration
management system but management systems of other engineering products
are suitable. Engineering Product management system 11 provides a work
space 23 view of a set of assets (generally engineered product) 13. This
engineered product 13 is formed of one or more assets 15, 19, 21. Each
asset 15, 19, 21 has respective versions or revisions, typically
referenced by a revision number. Different sets 22 of assets forming the
different versions 13a, b . . . n of the engineered product 13 employ
respective revisions of the assets 15, 19, 21. One of the illustrated
versions (sets of assets 22) of engineered product referenced 13a in FIG.
1 is formed of revision r=2 of asset 15, revision r=3 of asset 19 and
revision r=1 of asset 21. Other versions 22 of subject engineered product
13 use other revisions of assets 15, 19, 21.

[0022]Each version (set of assets) 22 of an engineered product 13 has a
state. For a given state, every asset 15, 19, 21 in the set 22 has a
location in space (repository 12 further described below) and in time
defining the state. Representation of asset location in memory follows
the format:

[0031]/asset [@ r] is the name of the subject asset and revision number r.

[0032]Each asset 15, 19, 21 has a set of revision numbers r. Each revision
number designates a specific state of the asset within the repository 12.

[0033]Common examples of assets are files and directories containing
diagrams or drawings, engineering specifications, source code of a
software program, requirements documentation, system models, system tests
and so forth. A significant state of an asset is saved as a revision of
that asset, and the sets of revisions (states) of a given asset are
stored in a tree or similar searchable data structure 17. Asset revision
trees 17 and assets 15, 19, 21 are held in a repository 12 illustrated to
the left side of the dashed lines in FIG. 1. Thus, FIG. 1 illustrates an
asset revision tree17a for asset 15, asset revision tree 17b for asset 19
and asset revision tree 17n for asset 21.

[0034]When an engineer or collaboration team member makes changes to an
asset 15, 19, 21, the set of changes 33 is recorded in respective asset
revision tree 17. In particular, a change set 33 lists the modifications
made to respective assets in one state to arrive at the next immediate
state of the assets. A change set 33 may be as short as a listing of
changes (one or more) made to one file (asset) or as expansive as
respective listings of changes made to many assets. The asset revision
trees 17 are maintained in this way for each version 22 of engineered
product 13a, b, c.

[0035]Specifically, engineered product management system 11 enables users
to produce and work with (edit, test, redesign, etc.) different
configurations or versions 22 of subject engineered product 13. The
engineering product management system 11 utilizes a revision manager 25
to manage the revisions made to each asset 15, 19, 21 and the resulting
revised assets thereof. Changes to assets 15, 19, 21 are made in the
context of workspace 23. The workspace 23 identifies the local changes
(change set 33') currently being performed to a version 22' of engineered
product 13(its assets 15' and 19' for example) of that workspace. When
the local changes 33' are completed and accepted or otherwise saved by
the users, the revision manager 25 records in respective asset revision
trees 17 the resulting new revised asset or asset revisions and the
corresponding changes (change sets) 33a, b, . . . n.

[0036]In a preferred embodiment, the revision manager 25 operates as a
tracking tool tracking changes 33, 33' for assets 15, 19, 21 and hence
tracking changes of state and corresponding resulting revisions of
assets. As such, the revision manager 25 is able to provide (produce)
various screen views that are helpful to end users or project team
members working on sets of assets 15, 19, 21. In one embodiment, there
are four particular views generated by the revision manager 25, namely a
working copy view 32, a file history view 34, a project view 35 and a
repository (or per asset timeline) view 37.

[0037]With the working copy view 32, the revision manager 25 enables a
user to view status information of an asset 15, 19, 21. For the subject
asset, there is a working copy and a repository copy. The revision
manager 25 establishes the working copy 15', 19' upon the user checking
out the asset 15, 19, 21 from the repository 12 and placing the asset (a
working copy 15', 19' thereof) in user workspace 23 on a local drive for
example. In the working copy view 32, the revision manager shows the
asset working copy 15', 19' relative to the corresponding repository copy
15, 19 and vice versa. This is accomplished using the cache or other
stored collection of changes 33' to the working (i.e., workspace 23) copy
15', 19' and the changes 33 associated with the repository copy 15, 19.
In a preferred embodiment, the revision manager 25 provides real time
display of changes 33, 33' in both of these directions, i.e., relative to
working copy and relative to repository copy.

[0038]Further, repository manager 25 provides a file history view 34
showing the log of change messages 33 for a single asset. Version history
tables 17 support this view 34. Additional details of one embodiment of
the file history view 34 and working copy view 32 are disclosed in U.S.
Provisional Patent Application 60/994,720 filed Sep. 21, 2007 for
"Computer Method and Apparatus for Software Revision Management"
(Attorney's Docket No. 2767.2005-000), incorporated herein by reference.
The repository per asset timeline view 37 is detailed in U.S. patent
application Ser. No. ______ by assignee (attorney's docket no.
2767.2012-000). More germane to the present invention is the project view
35 discussed next.

[0039]By way of background, in prior art engineering product management
systems, branches (hierarchies) of assets are typically shown as
vertices. In contrast, the present invention project view 35 (FIG. 2A-2c)
uses lines to indicate branches and subbranches of assets and further
illustrates relationships of the branches to a trunk as heretofore
unavailed by the prior art. The illustrated relationships represent
dependencies between assets and branches/subbranches comprising the
assets.

[0040]In addition, the prior art systems do not illustrate asset state
changes or a time order of asset revisions. Further, illustrations in the
prior art systems are typically only on a per asset basis, not whole sets
of assets as needed/wanted in team projects and complex software or
engineering product configurations. In stark contrast, the project view
35 and repository view 37 of the present invention enable users to see
asset state changes and a time view of asset revisions for whole sets of
assets. In some embodiments, there are functions and operations that
affect whole groups of assets. For example, performance indicators may be
associated with groups of assets. The performance indicator then
indicates how well the group of assets performed at the subject state.
Another example is the copy function which allows groups of assets to be
copied together at a time.

[0041]Further in shared file systems, file servers provide to users only a
way to look at contents (files) in space. In a repository system, such as
repository 12, one is concerned about space and time aspects of assets.
So there exists a need to show a timeline of asset changes 33 and the
corresponding resulting revisions (versions). In a single network
diagram, revision manager 25 of the present invention displays both a
timeline view of assets and changes 33 to state of an asset. This
graphical display of the history of changes 33 to sets of assets in
engineering product management system 11 is called the project view 35
and is described with reference to FIGS. 2a through 2c and FIG. 5.

[0042]By way of overview, the project view 35 displays a trunk 26,
branches 29a . . . n, state changes 30a . . . n of assets and tags 27a .
. . n involved in an engineered product project along with various
graphic indicators 28, 36, 39, 40. There are numerous configurations that
each of these elements can assume. For each user (project member) there
is a respective branch 29 and corresponding subbranches 29h. Each of
these branches 29/subbranches 29h are shown below trunk 26 in a manner
illustrating their relationship to trunk 26. Each change of state of an
asset is rendered as a grey dot 30 along a pertinent branch (of a
respective user). Each grey dot 30 coupled with a respective tag 27
represents a point at which the resulting revision/version of an asset is
committed and available for use by users. The project view 35 has two
scaling modes: temporal and sequential as illustrated in FIGS. 2b and 2c.
In sequential mode (FIG. 2B), the left to right increments correspond to
changes in state and thus sequence of revisions. This is illustrated by
grid lines aligning with commit points 30. In temporal mode (FIG. 2c),
the left to right increments correspond to steps in time, thus the grid
lines do not often align with commit points 30 in that viewing. Both
modes show both types of changes (i.e., sequential changes to state and
order of changes over time).

[0043]As illustrated in FIGS. 2a-2c, there is a respective horizontal
line, (branch 29 and associated/related subbranches 29h) per user
indicating a hierarchy of assets being worked on by the user. There may
be a subbranch 29h for each variation or concept by the user. Each
branch/subbranch 29 may be labeled to indicate the respective user.

[0044]At the top of project view 35 is the trunk line 26. The spatial
layout of the branches 29 relative to trunk 26 illustrate the
dependencies between branches 29/subbranches 29h and assets/versions of
those branches 29. A copy of an asset is indicated by a dashed line copy
path 43 from the starting or source asset. The asset copy and the source
asset are represented by respective circles, each being named the same
(but with different revision number and repository memory location) in
recognition of the copy relationship. The point of intersection of a
branch line 29 and a subbranch 29h (or a brach29/subbranch 29h and a copy
path 43) indicates the state of the subject asset(s) affected. That is, a
copy of the subject asset(s) at that state (at the time corresponding to
the point of intersection of lines 29, 29h, 43) is used in the respective
resulting subbranch 29h or copy path 43 destination.

[0045]Trunk 26 and each branch 29 are said to contain the respective
hierarchy of assets. Each trunk/branch line 29 is a handle to the asset
hierarchy as stored in repository 12. This handle is implemented using a
hyperlink or similar technology and following the format for asset
location in memory described above. Preferably the trunk line 26 is a
link (hyperlink) to the file directories of the asset hierarchy and thus
serves as the "root" for the displayed project.

[0046]As mentioned above, in one embodiment, the project view 35 employs
grey dots (filled circles) 30 to indicate state changes of assets, and a
tag 27 coupled to a grey dot 30 to indicate when a change of state is
sufficiently committed to for other users purposes. Preferably tags 27
are graphically represented by a pentagon shaped symbol. Other geometric
shapes (polygons) or symbols are suitable for representing tags 27. Once
created, tags 27 are typically read-only in some embodiments.

[0047]Each of the so called commit points 30 represents a change of state
to one or more assets at that point in time. The enumeration of changes
is called a change set 33. In a preferred embodiment, the change set is
implemented as a list 33. The list of changes 33 is recorded for or at a
specific version of an asset in repository 12 as illustrated in FIG. 1.
The displayed commit point 30 preferably is a handle to change set or
list 33 using hyperlink or other suitable technology. The list contains
the path of each item that was modified (e.g.,
svn+ssh://host/repo/dir/file.txt) as well as an indication of what kind
of change was made (e.g., added, removed, modified). This list of changes
33 is commonly known as a change set, but is also referred to as change
paths.

[0048]In one embodiment, user selection (through a graphical user
interface) of a commit point 30 operates to generate a query of the
repository 12 for change sets 33 of the asset corresponding to the
selected commit point 30. The repository 12 is configured (e.g. using
database technology) to respond to the query and returns a corresponding
file storing the change sets 33 of the asset.

[0049]The latest state of an asset or set of assets is represented by a
head element 41. In a preferred embodiment, head 41 is implemented as a
block (square) or circle at the distal end of each trunk26/branch 29. A
block shaped head indicates that the branch 29 is still viable, and a
circle head indicates a deleted branch 29 in one embodiment. Each head 41
serves as or effectively is a handle for the trunk 26/branch 29 coupled
thereto. The handle may be implemented using hyperlink or similar
technology. Thus, selecting this handle is equivalent to requesting "the
latest stuff" (includes workspace 23 changes 33'), which is not
necessarily the same as requesting "the latest revision/version"
committed to repository 12 where a revision/version is a specific state
in the repository 12 as discussed above.

[0050]Each tag 27 may have one or more performance indicators 28
associated with it. Restated a performance rating may be associated with
each change in state (revision) of an asset. The respective performance
indicator 28 represents the performance rating. In one embodiment, each
performance indicator 28 is represented by a block (square), each block
being a single metric. Each metric may have one or more asset groups
associated with it. The colors of the performance indicator 28 blocks
correspond to the metric score. In that sense, the performance indicators
are color coded in some embodiments. Arrows 39 (FIG. 2A) in the
performance indictor 28 block indicate whether the metric score has gone
up or down since the previous tag 27 with that metric. Grey blocks in the
performance indicator 28 blocks indicate a change to the preference
curves used to generate the metric score.

[0051]Various performance metrics and performance calculations known in
the art are suitable. Preferably a separate program procedure or function
determines performance per asset revision (state change) and stores
respective performance metric scores of asset revisions in repository 12.

[0052]Preferably revision manager 25 also provides in project view 35
indications 40 (FIG. 2A-2c) of annotations or comments by a user. The
annotations may regard the performance score, performance metric used,
change in performance score calculation parameters or factors and the
like of performance indicators 28 and metric change indicators 39. The
annotations may regard the corresponding asset/commit points 30 state of
changes, copy path 43, dependencies and so forth. Upon a user interacting
with an annotation indicator 40 according to the graphical user interface
of project view 35, revision manager 25 displays or otherwise renders the
text of the corresponding annotations and/or comments. Annotation or
comment technology known in the art supports operation of annotation
indicators 40.

[0053]In order to indicate the existence of a working copy 15', 19' of an
asset or set of assets, project view 35 displays a working copy indicator
36. In a preferred embodiment, working copy indicator 36 is displayed
next to the branch name from which the subject asset(s) were obtained
(sourced). If there is more than one working copy 15', 19' of a subject
asset/set of assets, then project view 35 displays a respective working
copy indicator 36 for each working copy. For example, two working copy
indicators 36 next to one (a same) branch name indicates that there
exists two working copies 15', 19' of the same asset or set of assets.

[0054]Each working copy indicator 36 is a handle to the respective working
copy 15', 19' in the user's workspace 23. The handle may be implemented
using hyperlink or similar technology. The working copy indicator 36
provides a link to the working copy or a link to status information about
the differences between a working copy 15', 19' and the trunk 26/branch
29/tag 27 from which it was checked out.

[0055]In some embodiments, the revision manager 25 creates the project
view 35 as follows and illustrated in FIG. 5. The revision manager 25
starts with the data stored in version history tables 17 and the
workspace 23 data of project users (step 61). In particular, revision
manager 25 queries the repository 12 for logs 17 within a pertinent time
period, and then queries the repository/logs based on asset names (to
deduce copy paths 43 for example) or other revision aspects. The revision
manager 25 then parses the data (step 63) and corresponds the resulting
parsed pieces to respective graphical elements (head 41, branch 29,
subbranch 29h, tag 27, commit point 30, asset working copy 15', 19' and
corresponding working copy indicators 36, etc.). Logic for deducing view
elements from the history log data and workspace 23 data may also be
employed. Preferably revision manager 25 applies color coding and a
visual grammar (detailed later) to make these correspondences at step 63.

[0057]Continuing with FIG. 2B, project view 35 is rendered in sequential
mode. In this mode, each grid (vertical) line is a point in the sequence
of revisions. Thus, the grid lines are aligned with commit points 30 and
are numbered with revision numbers (along the bottom of the figure). The
revision numbers increase from left to right but not necessarily at a
regular rate (not by a same amount from one grid line to the next).

[0058]FIG. 2c illustrates the project view 35 in temporal mode. Here the
grid (vertical) lines demark respective points or moments in time, rather
than the points in the sequence of asset revisions in FIG. 2B. In one
embodiment, date and time stamps are used to label each gridline in
project view 35 in temporal mode as shown in FIG. 2c.

[0059]Also at 44 in FIG. 2c is shown a commit point 30 with associated or
coupled tag 27 but no metric blocks/performance indicators 28. In any
mode (sequential or temporal), revision manager 25 may show commit points
30 in project view 35 coupled to zero or one tag 27, and tags 27 coupled
to zero, one or more performance indicators 28.

[0060]There are two types of assets: containers and non-containers. Files
are examples of non-container assets, for example, a spread sheet or a
text document. Directories are examples of container assets. The branches
29/subbranches 29h and commit points 30 in project view 35 are each
effectively a directory.

[0062]In another embodiment, the present invention provides project view
35 overlaid with (or otherwise effectively combined with) project
planning and/or scheduling information and the like as follows. Project
planning tools (such as Microsoft Project) generate a file of
information. The information typically includes dates, names and/or
contents of project phases, tasks, schedules, gates and reviews, for
example in architecture and construction industries. Other information
and other industries may also apply and may be included. Revision manager
25 obtains or otherwise accesses as input the file generated by the
project planning tool. This may be established at step 61 of FIG. 5. Next
(as part of step 63) revision manager 25 analyzes the project planning
tool generated file and determines the project phases, schedules, tasks,
gates, etc. with respect to project view 35 constructs. That is, revision
manager 25 converts the project planning/scheduling file into vertical
line entries (or the like) for overlaying onto project view 35. The
results of this conversion (step 63) are stored as an XML or similar
file. Step 65a, b include the saved XML file in the generation of project
view 35 by overlaying the items/e.g., vertical line entries from the
saved file onto commit points 30, branches 29/26, tags 27, etc. of
project view 35 of FIGS. 2a-2c. The combination of the overlaid
information and the above described project view 35 information provides
an integrated view of a project plan with actual (current) state changes
of assets as held in repository 12 and workspace 23. Other techniques (in
addition to or substitution as "overlaying") for rendering the project
planning/scheduling information relative to the project view 35 are
suitable.

[0063]Accordingly throughout the project view 35 and repository view 37,
the present invention employs a visual grammar, i.e., an enumeration of
the different branch 29/subbranch 29h and tag 27 states and how the
configuration manager 11/revision manager 25 will render them. The
revision manger 25 is not the only sub-version client (working module),
so there are a number of cases where the revision manager 25 must be able
to display a repository 12 state even if the revision manager is not
designed to put the repository 12 into that state. The visual grammar of
the preferred embodiment is detailed in Appendix I.

[0064]Each case enumerated in Appendix I includes a brief description of
the state, an image of what this state looks like graphically and svn
command line examples of how the repository 12 can be put into the state
for that case. In addition, each case may include SVN Log entries that
correspond to the state.

[0065]Further, it is noted that each view 32, 34, 35, 37 (i.e., working
copy view 32, file history view 34, project view 35 and repository/per
asset timeline view 37) has a network memory location. The location is
specified as a URL that uniquely locates an asset and uses the form

[0066]URL@NNN

where the "URL" is the asset location in space and the "@NNN" is the asset
location in time. The "@NNN" specifies at revision number NNN as common
in the industry. Thus, the present invention views (i.e., working copy
view 32, file history view 34, project view 35 and repository/per asset
timeline view 37) provide a view into the repository 12 in both time and
space, where in one embodiment the grey dots (in per asset timeline view
37 and at 30 in FIGS. 2a-2c) represent past revisions/versions of an
asset and the unfilled rectangle heads 41 represent the current
(workspace 23) asset revision contents. In the prior art, only a view
into the file server in space was provided and not a view in time and
space as in the present invention.

[0067]FIG. 3 illustrates a computer network or similar digital processing
environment in which the present invention may be implemented.

[0068]Client computer(s)/devices 50 and server computer(s) 60 provide
processing, storage, and input/output devices executing application
programs and the like. Client computer(s)/devices 50 can also be linked
through communications network 70 to other computing devices, including
other client devices/processes 50 and server computer(s) 60.
Communications network 70 can be part of a remote access network, a
global network (e.g., the Internet), a worldwide collection of computers,
Local area or Wide area networks, and gateways that currently use
respective protocols (TCP/IP, Bluetooth, etc.) to communicate with one
another. Other electronic device/computer network architectures are
suitable.

[0069]FIG. 4 is a diagram of the internal structure of a computer (e.g.,
client processor/device 50 or server computers 60) in the computer system
of FIG. 3. Each computer 50, 60 contains system bus 79, where a bus is a
set of hardware lines used for data transfer among the components of a
computer or processing system. Bus 79 is essentially a shared conduit
that connects different elements of a computer system (e.g., processor,
disk storage, memory, input/output ports, network ports, etc.) that
enables the transfer of information between the elements. Attached to
system bus 79 is I/O device interface 82 for connecting various input and
output devices (e.g., keyboard, mouse, displays, printers, speakers,
etc.) to the computer 50, 60. Network interface 86 allows the computer to
connect to various other devices attached to a network (e.g., network 70
of FIG. 3). Memory 90 provides volatile storage for computer software
instructions 92 and data 94 used to implement an embodiment of the
present invention (e.g., revision manager 25, and code for generating
project view 35 and per asset timeline screen view 37 with asset revision
history 52 detailed above). Disk storage 95 provides non-volatile storage
for computer software instructions 92 and data 94 used to implement an
embodiment of the present invention. Central processor unit 84 is also
attached to system bus 79 and provides for the execution of computer
instructions.

[0070]In one embodiment, the processor routines 92 and data 94 are a
computer program product (generally referenced 92), including a computer
readable medium (e.g., a removable storage medium such as one or more
DVD-ROM's, CD-ROM's, diskettes, tapes, etc.) that provides at least a
portion of the software instructions for the invention system. Computer
program product 92 can be installed by any suitable software installation
procedure, as is well known in the art. In another embodiment, at least a
portion of the software instructions may also be downloaded over a cable,
communication and/or wireless connection. In other embodiments, the
invention programs are a computer program propagated signal product 107
embodied on a propagated signal on a propagation medium (e.g., a radio
wave, an infrared wave, a laser wave, a sound wave, or an electrical wave
propagated over a global network such as the Internet, or other
network(s)). Such carrier medium or signals provide at least a portion of
the software instructions for the present invention routines/program 92.

[0071]In alternate embodiments, the propagated signal is an analog carrier
wave or digital signal carried on the propagated medium. For example, the
propagated signal may be a digitized signal propagated over a global
network (e.g., the Internet), a telecommunications network, or other
network. In one embodiment, the propagated signal is a signal that is
transmitted over the propagation medium over a period of time, such as
the instructions for a software application sent in packets over a
network over a period of milliseconds, seconds, minutes, or longer. In
another embodiment, the computer readable medium of computer program
product 92 is a propagation medium that the computer system 50 may
receive and read, such as by receiving the propagation medium and
identifying a propagated signal embodied in the propagation medium, as
described above for computer program propagated signal product.

[0073]While this invention has been particularly shown and described with
references to preferred embodiments thereof, it will be understood by
those skilled in the art that various changes in form and details may be
made therein without departing from the scope of the invention
encompassed by the appended claims.

[0074]For example, the present invention may be implemented in a variety
of computer architectures. The computer network of FIGS. 3 and 4 are for
purposes of illustration and not limitation of the present invention.

[0075]Further, various color coding or color schemes may be applied to the
various above described screen views 35, 37. For example, in one
embodiment branch lines 29 are displayed in yellow, tags 27 are displayed
in grey particular polygon shape, trunks 26 are red lines, assets are
represented by grey dots 30, annotations are indicated by white circles
40 and performance indicators 28 are respective shades of other colors.
Other colors or shades and other combinations of colors, shapes and line
drawing (e.g., solid lines, broken lines, dotted lines, etc) are
suitable.

[0076]Further where the above describes overlaying project
planning/scheduling information on project view 35, it is understood that
underlaying techniques/methods and the like may be similarly used.
Effectively project view 35 information and project planning/scheduling
information are displayed relative to each other using layering or other
display configuring (configurations) given the foregoing discussion of
the present invention. The recitation of "overlay" is not intended to be
strictly limiting but is instead for purposes of illustrating effect.
Likewise the terms "project planning" and "project scheduling" are
interchangeable.

APPENDIX I

[0077]Visual Grammar

[0078]This is an enumeration of the different branch and tag states and
how the application will render them. The revision manager is not the
only subversion client, so there are a number of cases where the revision
manager must be able to display a repository state even if the revision
manager is not designed to put the repository into that state. Each case
enumerated below includes a brief description of the state, an image of
what this looks like graphically, and svn command-line examples of how
the repository can be put into the state for that case. In addition, each
case may include SVN Log entries that correspond to the state.

[0079]Overview

[0080]The project view displays the trunk, branches, and tags in a
project. It also shows each change of state (rendered as dots, each of
which represents a revision) as well as performance indicators
(optionally associated with tags). The view has two scaling modes:
temporal and sequential. In sequential mode, the left-to-right increments
correspond to changes in state. In temporal mode, the left-to-right
increments correspond to steps in time. Both modes show both types of
changes, i.e. sequential changes to state and order of changes over time.

[0081]The per-asset view displays a revision history and asset contents.
The revision history is a line with dots. Each dot represents a change of
state to the asset (a revision point). For a given location, there is one
and only one timeline. Each timeline may be rendered in one of two modes:
show all and location only. In show all mode, every revision is show for
the asset, even if the revision happened to the asset before it was
copied to the viewed location. In location only mode, display is limited
to revisions made when the asset was in the viewed location.

[0082]There are two types of assets: containers and non-containers. Files
are examples of non-container assets, for example a spreadsheet or a text
document. Directories are examples of container assets.

[0083]Overview--Constructs

[0084]revision head tag with

[0085]indicators

[0086]working copy

[0087]indicators

[0088]asset

[0089]copy

[0090]branch Each line represents a branch. The trunk and each branch
contain a hierarchy of assets; each trunk/branch line is a handle to the
asset hierarchy.

[0091]change set The list of changes at a specific revision. The list
contains the path of each item that was modified (e.g.
svn+ssh://host/repo/dir/file.txt) as well as an indication of what kind
of change was made (e.g. added, removed, modified). Also referred to as
changed paths.

[0092]commit point Each commit point represents a change of state to one
or more assets at that point in time. The enumeration of changes is
called a change set.

[0093]head The latest state of an asset or set of assets. The block at the
end of each trunk/branch is a handle for the head of that trunk/branch.
Selecting this handle is equivalent to "give me the latest stuff", which
is not necessarily the same as saying "give me the latest revision".

[0094]performance indicators Each tag may have one or more performance
indicators associated with it. Each block is a single metric. Each metric
may have one or more asset groups associated with it. The colors in the
blocks correspond to the metric score. Arrows in the block indicate
whether the score has gone up or down since the previous tag with that
metric. Grey blocks in the blocks indicate a change to the preference
curves used to generate the metric score.

[0095]revision A specific state in the repository.

[0096]tag Each tag is a hierarchy of assets. Once created, tags are
typically read-only.

[0097]working copy indicator The working copy indicator is a handle to a
working copy. It provides a link to the working copy or a link to status
about the differences between a working copy and the branch/trunk/tag
from which it was checked out.

[0098]Overview--Status Indicators

[0099]The working copy status indicates the status of items on the file
system relative to items in the repository. The status indicators
include:

[0100]marked for addition

[0101]marked for removal

[0102]has conflicts

[0103]has changes

[0104]contains items that have changes

[0105]no changes

[0106]The repository status indicates the status of items in the
repository relative to the items on the file system. The status
indicators include:

[0107]has changes

[0108]contains items that have changes

[0109]no changes

[0110]Project View Cases

[0111]The cases enumerated below are organized into groups: one for asset
copies, one for branches, and one for tags.

[0112]Asset Copy--From One Branch To Another

[0113]Copy one or more assets from one branch to another. This operation
may replace or add to the assets in the destination branch.

[0125]Create a branch by copying one or more assets from a location
outside a project as well as one or more assets from a location within a
project.

TABLE-US-00007
cannot be done via command line
log goes here

[0126]Branch Create--Create Multiple Branches

[0127]Create more than one branch in a single operation.

TABLE-US-00008
cannot be done via command line
log goes here

[0128]Branch Create--Create Branch By Making a New Directory

[0129]Create a branch by creating a new directory.

TABLE-US-00009
svn mkdir REPO/PROJECT/branches/b1
log goes here

[0130]Branch Delete

[0131]Delete a branch.

TABLE-US-00010
svn rmdir REPO/PROJECT/branches/b1
log goes here

[0132]Branch Unknown

[0133]A branch may have no history associated with it, but does have
commits. The branch origin is unknown.

[0134]Branch Restore

[0135]Restoration of a branch is accomplished by a delete then a create.
This is not a new configuration, but rather a composition of two others
(delete and create). Here are some examples of what restoration of a
branch looks like.

[0136]Branch Replace

[0137]Replacing a branch is the same thing as either an asset copy (when
some or all branch contents are replaced) or a delete-create (when a
branch is deleted then replaced by a new branch with the same name).