>No, actually I believe it *is* technically impossible. IIRC, the "cvs log"
>output does not fully detail the revision graph when branches are present.
>It isn't always possible to determine the predecessor revision in certain
>cases. And especially if somebody forces specific revision numbers -- you
>can't just say "1.(rev-1)" to figure out the predecessor.
>The ,v files, on the other hand, *do* contain all of the predecessor
>information, so it can properly compute the branch graph for conversion.
I believe you can determine the entire branching structure, but it is not
easy. This is partly because a branch can exist with no revision
(I call this a 'bud', which will 'grow' into a branch when revision are
committed to it). These have the version numbering format x.x.0.x or
x.x.x.x.0.x (extrapolate for deeper branches). I did this for the version
graphs in tkCVS (see http://sourceforge.net/projects/tkcvs/), which are
derived completely from capturing and parsing 'cvs log' output. The have
changed look of the graph since I worked on it, but I am sure the parsing
heuristics are still the same. To see that it can be done for arbitrarily
complex source code revision history, see the screenshot
http://www.twobarleycorns.net/tkcvs/tkcvs-log.gif .
A lot of CVS graphing tool for the 'log' subcommand dont handle this
gracefully, nor do they handle arbitrarly deep branching. This is
understandable given how hard it is to manage deep CVS branches and
merges, unless you have a good CM process and tag meta-data policy.
Most code-shop's just dont do branchng for this reason, so a lot
of tools just handle the simplest case. Organising code change/repair
by brancing is something I hope Subversion will encourage.
Note tha there are no merge arrows, because CVS doesn't keep this
inforamtion, hence the tags storing this like the tag
'tkcvs6_3_merged'. I am not clear yet how Subversion handles the issues
in repeated merges - especially with keyword expansion (e.g. the horror
of repeatedly merging CVS code branches with $Log$ expanded)
Not shown in this output are bud's.
**********************************************************************
IMPORTANT
The contents of this e-mail and its attachments are confidential and intended
solely for the use of the individual or entity to whom they are
addressed. If you received this e-mail in error, please notify
the HPA Postmaster, postmaster@hpa.com.au, then delete
the e-mail.
This footnote also confirms that this e-mail message has been swept for
the presence of computer viruses by MimeSweeper. Before opening or
using any attachments, check them for viruses and defects.
Our liability is limited to resupplying any affected attachments.
HPA collects personal information to provide and market our services.
For more information about use, disclosure and access see our Privacy
Policy at www.hpa.com.au
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 3 05:36:43 2002
