Converting unconventional CVS tags / only select files tagged

"Mark A. Ziesemer" <[email protected]>
Newsgroups gmane.comp.version-control.subversion.cvs2svn.user
Message-ID <[email protected]>
The CVS repository I am trying to convert to SVN using cvs2svn has a
somewhat unconventional tagging structure.  (Branches are pretty much
non-existent, and I don't believe are part of the issue.)  Basically, over
half of the CVS tags were named after a task, and only the few files
involved in that task were tagged in CVS.  This is in contrast to the more
conventional approach where the same few files are edited, but then all
files at that point in the project are tagged.

This leads to 2 issues:

1)  Due to the nature of the SVN repository, I doubt this has any
significant impact on space or performance.  However, the revision history
becomes rather confusing.  Instead of seeing a "tag" directory created, with
the tagged files added - the root is shown as the only addition, with
everything else that wasn't included shown as a deletion.  Parent
directories that are not included at all are shown as deleted, while files
not included next to other files that are included are also shown as
deleted.

Instead, I would ideally expect to see only all the files that were included
in the CVS tag as additions.

Overall, I also don't think that this is the most optimal solution in terms
of an efficient revision diff.  For example, in a situation where 3 files
are added in a directory containing 200 files, the revision diff will
contain 197 deletions instead of 3 additions.

2)  In trying to build the commit database on the converted SVN repository
in ViewVC, the above inefficiencies lead to extreme performance issues,
requiring many times the amount of diff's to be generated and calculated in
these instances, than if the opposite approach were used.  Even under a
powerful multi-processor system running multiple instances of svndbadmin
with split revision ranges, I'm looking at many days to commit about 5,000
revisions.  Even if / once completed, this will result in excessive file
rows included for each of these revisions, as well as making searches
against the commit database ineffective.  (A search for a file would not
find commits of tagged files, as only deletions were recorded for the
revision, not additions.)

In the current state, I do not think we will be able to include revisions
prior to the cvs2svn conversion in the commit database, unless I can find a
way to only index non-tag-related revisions.  Another alternative may be
only converting trunk without including the tags in the conversion at all -
but I don't know that loosing the tag history is an option.


I am certainly not proposing that cvs2svn should reverse the current
functionality.  However, I am wondering if there would be any issues in
including an option such as a "percent files included" threshold - such that
if x% of files aren't tagged in a given folder, the parent folder is created
instead of copied, and then the tagged files included as additions rather
than everything else being deleted.  Both approaches could be taken per
revision, with the % threshold being calculated on a per-folder basis.

Otherwise, would using a filter on a SVN dump file be a better option, or
even feasible?  Would the necessary data even be included in the dump file
to convert the tag revisions from being deletion-based to addition-based?

Are there any other suggestions for other or better ways of addressing this
issue?

If requested, I could open an enhancement request for this, and attach an
archive of a small example CVS repository, cvs2svn logs of the conversion,
as well as the converted SVN repository for demonstration purposes.

Thanks!!

--
Mark A. Ziesemer
www.ziesemer.com

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2621522

To unsubscribe from this discussion, e-mail: [[email protected]].
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.