[Monotone-devel] RFC: cvs import/pull and */CVS/* files

[Christof Petig]

Last month Daniel Carosone proposed to store the corresponding CVS
revisions for a given (imported or cvssynced) monotone revision within
the usual files: */CVS/Entries, */CVS/Repository instead of using a
hidden file (like .mt-cvs_revisions).

I see some drawbacks and some benefits, what do you think about it
(remembering the corresponding revisions is vital for cvssync and would
come quite handy if you cvssync with an cvs_imported repository, so I
think whether or not this should be done is unquestionable)

- cvs_push can not alter a given revision, so it has to remember the
file states within a certificate, if CVS revision information is part of
the tree this information is invalid once you commit to a cvs imported
branch. You might not notice this easily. E.g. the CVS/Entries
information is incorrect if you commit within monotone.

Using CVS/* might lurk people into using cvs on a monotone based tree
and getting strange merge results (because the revision information
is/will be outdated by an cvs_push and the file contents cannot change
on push)

- If the information within CVS/* is current (e.g. by using an
unmodified pulled/imported tree) the CVS commands continue to use as
expected.

- I will provide a way to synchronize the files with the CVS revisions
(e.g. $Id$ within a file) and this command can also update the
synchronisation information.

- Using a file to store the revision information uses well known delta
codings!

- There is no easy way to tell whether a revision information is
current, absence of a certificate was a good indicator in the past.

- If you use CVS/* you have to parse and check a lot of files to get all
corresponding revisions.

What do you think:
- use */CVS/* to store revision information
- use .mt-cvs_revisions to store revision information
- continue to use delta encoded certificates (fragile)

  Christof

signature.asc
Description: OpenPGP digital signature