> > I set up a sample repository at:
>
> (...)
>
> Great, thanks. You prevented the problems that made me give up by simply
> not converting the tagged releases we have of each package. So it'll be
> harder to find back a specific release this way, at least, those of
> before the migration. I'm not really sure what I think of this, but as
> otherwise this migration might be much delayed even further...
Looking a little further into this (which I obviously should have done
sooner) here are some more observations about the transition from CVS to
Subversion:
After performing a default cvs2svn import, the directory heirarchy is:
-trunk
-<package_name>
-branches
-<branch_name>
-<package_name>
-tags
-<tag_name>
-<package_name>
The default svn-buildpackage directory heirarchy type 2 is:
-trunk
-<package_name>
-branches
-<package_name>
-<branch_name>
-tags
-<package_name>
-<tag_name>
It would be very easy to run cvs2svn, then issue a bunch of svn mv
commands to create the desired heirarchy.
At this point my biggest question is: what layout exactly do we want?
The directory structure outlined above has the advantage that it is
supported by svn-upgrade.
It also has the flexibility that we could always decide to use the tags
and branches in the way that we want. For example, we could create
branches for Debian releases.
I also have a question regarding importing the tags:
Most of the tags are RELEASE_<VERSION> tags. The non-RELEASE tags are
debian_version_0_<version>, DRAFT, IMPORT_JETTY, initialImport,
JAVA_PACKAGE_0_1_2, and start. Can someone comment on which if any of
these should really be preserved.
I look forward to receiving feedback on these issues so that we can move
forward with the migration. :-)
cheers,
Charles
--
She eyed
His beard
And said no dice
The wedding's off--
I'll cook the rice
Burma-Shave
http://burma-shave.org/jingles/1951/she_eyed
Attachment:
signature.asc
Description: Digital signature