demerphq wrote:
In the thread i posted I aksed a specific question, how
will we know that we have a vc that is sufficient to track the current
change history.
*My* definition is as follows:

1) Checking out a revision in Perforce should result in exactly the same
files as the same revision in the VCS to come (strict 1 to 1 mapping);

2) All special "binary" files must be preserved across the conversion -
this includes some CR/LF files that must be preserved as is (this is a
special case of #1);

3) Any copy-from information present in Perforce (e.g. integration,
copy, rename) must be present in the new VCS system in an equivalent
form (no revision history lost);

4) All log messages must be completely equivalent (this is the only one
that is easy).

Note that #1 is going to be challenging, because a Perforce repository
can skip change numbers (i.e. you can actually obliterate a change). I
have already run across this in the p42svn process (I just create empty
commits to keep the repos in sync). There are far too many places where
we reference specific change numbers to lose that mapping. Note also
that this could be emulated by creating tags in the local VCS lingo that
correspond to the change numbers for historical purposes.

For testing purposes, a trivial script which checks out each change in
each system and compares it would be sufficient to satisfy #1 and #2.
Testing #3 is going to be trickier; it may be necessary to write an out
of band script that parses the Perforce log entries and tests to see
whether the new VCS contains the appropriate linkage.


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2019 Grokbase