converting between revision control systems (was Re: [arch-users] tag docs)
Mark Ferrell
arch-users@lists.fifthvision.net
Thu, 13 Mar 2003 13:10:49 -0800 (PST)
--- Tom Lord <lord@emf.net> wrote:
>
> I for one have no desires to convert from RCS to CVS to SVN to
> Arch.
>
>
> Putting aside the question of converting via SVN ... I'm starting to
> feel a little dubious about the value of bulk auto-converting from
> _any_ revision control system to _any_ other (unless the source and
> target have perfectly isomorphic models, or the target model has a
> subset which is perfectly isomorphic to the source).
Aye, bulk auto-conversion isn't something I am aiming for. Originaly
it had been my intent, but it proved to be, as you seem to have
expected, a bit procarious.
My end goal is to allow continuous upate between an existing CVS
repository and an Arch repository (and vice versa). Originaly my
cvs2arch script, as I mentioned, did attempt bulk conversion, and
equally foolish, automatic 'guessing' as to the best policy. Part of
what needs to be done is set strict policy on CVS usage.
[I am still looking into MetaCVS to be used on the server side to
assist with some of this]
I have since then started removing what where core components of the
cvs2arch script and attempting to rebuild necessary functionality into
smaller helper scripts. The vast majority of these scripts end up with
benefits for using CVS as well as being usefull for a CVS to Arch
conversion, and Arch to CVS. What I am trying to work towards now is
basicly a single frontend command with a collection of sub-commands.
Something like cscvs (or cvscs?) for ChangeSet CVS, some of the
sub-commands that I am 'hoping' to implement as I pull apart my old
cvs2arch frontend are:
lint: assist with sifting through a CVS repository and locating
any inconsistancies in tags, branches, ect.. reporting the
patchset they occure at and what not so that they can be
fixed.
cache: the sheer scale of the amount of data that needs to be
pulled from a CVS server in order to gather appropriate
information about the repository for locating changesets
makes it painfull to continually retrieve the same data.
The cvscache will store relivant data locally and allows
for dramatic reductions in time in locating any new
changesets since the last cache update.
chroot: Facilitate changing of a CVS repositories CVSROOT location,
there is a tool for this already in the debian cvsutils
package, and I have found it quite usefull if the previous
server I was using is currently down and I wish to switch
to a mirror. This has the potential to effect the cache,
so a new version is needed.
checkout: checkout a CVS repository at a given changeset number
update: update a checked out CVS repository to a given changeset
tag: tag a given changeset
log: report a log of a given changeset
diff: generate a diff between 2 changesets
toarch: push changesets from a CVS repository into an Arch
repository
fromarch: pull changesets from an Arch archive into a CVS repository.
tocvs: push changesets from one CVS repository to another. This
is actaully really important, as I have only recently come
to realize. The problem is that the vast majority of CVS
repositories are quite frankly busted. I have come to the
firm conclusion that no-one should ever be allowed to
commit a change directly onto the MAIN. I have gathered an
extensive list of problems that can result in a CVS
repository as a result of this, though most of them are
transparent to end users, it dramaticly effects inner
operability of CVS w/ some other system like Arch. The
'tocvs' command would allow one to migrate changesets from
the MAIN to a branch in another repository.
This list will likely be modified, appended, ect.. as I go along, but
to me one of the important issues to nail down was to be able to
continuously drag in updates from a CVS repository into Arch, and the
bulk approach just didn't cut it.
> If the target system is not a strict superset of the source system,
> then any such conversion will alter history -- it's going to throw
> out information or, at least, create a need for new tools that can
> recover that information from the altered format.
One of the delimas I ran across early on was "what do we do with tags
that exist on only a few files in a changeset?". I had originaly
simply planned on ignoring them in cvs2arch, but that really didn't
help the end user much (at the time I was the end user). Then I had
the not-so-brilliant idea to add an argument to cvs2arch to change tag
conversion behavior. --strict-tags --ignore-bad-tags --weak-tags, so
on and so forth. I ended that venture shortly into it as it really
over complicated the core of the rlogparse.py script that was
responsible for parsing the data to begin with. I decided that
rlogparse should have fairly strict, well defined behavior that wasn't
easy to change into unexpected behavior, thus allowing for a better
amount of repeatabilty.
> I can imagine wanting, for convenience purposes, to go back and store
> historic releases or milestones in a new arch deployment -- but I
> think in a lot of situations, you'd also want to just freeze your CVS
> repository, keep it around for a long time, and start a fresh arch
> repository for work going forward.
I really wanted a full 100% conversion. Admittedly I will never likely
achieve a "100%" conversion, but I am willing to suffer modifying tags
in the CVS side to make it behave a bit better for this purpose. So
far that is the only part that has been a problem. Hopefully the cscvs
frontend, if I can get the others to use it, will actually allow for
later 100% conversions as it will enforce the appropriate behavior.
> What's the goal of a bulk auto-conversion of historic data, anyway?
> Just so you can `rm -f /usr/local/bin/cvs'?
For me I want to use Arch, but various other developers still want to
use their CVS repositories. Until that changes I need a fairly
bi-directional conversion tool and in order for that to be as clean as
possible I need to enforce some sort of policy on how CVS is used.
=====
Mark Ferrell
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com