monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] quick&dirty CVS export


From: Lapo Luchini
Subject: [Monotone-devel] quick&dirty CVS export
Date: Sat, 07 Oct 2006 15:44:18 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 Hamster/2.0.0.1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While brooding over FreeBSD's "wanted features ni a VCS" I found
myself thinking about one of the few we do not have "real" support no
the mainline yet: FeatureCVSExport.
I also talked quite a bit about it with a friend of mine and he told
me that probably that "wanted" CVSExport feature doesn't necessarily
mean "every single revision should be also on CVS as accurate as
possible", as CVS would be used only during migration anyway, and
would probably be considered as "legacy support" anyway.
I thought of a quick&dirty way to export a linear CVS history out of a
(possibly very active and thus containing often various heads) branch:

- - at one point in time the branch is merged and a revision A gets
committed as version 1.123
- - on every received revision B a commit-hook gets called that commits
it to CVS if and only if B is a strict descendant of A

This simple rule should extract a single linear history out for a
complex one, with the one limitation that it would represent only a
single line's commits 1:1 and should then contain "all the others"
using a summary of log messages.

Example given:

A: Initial revision
A1 son of A: added nifty feature.
A2 son of A1: corrected nasty bugs.
B1 son of A: updated Italian translation.
B2 son of B1: fixed a few translation bugs.
C son of (A2,B2): merge.

Imagining their commit (or, better put: receive) time on the central
server is the one stated in the example (A, A1, A2, B1, B2, C) this
would (should) produce on CVS the following history:

1.123: (A) Initial revision.
1.124: (A1) added nifty feature.
1.125: (2) corrected nasty bugs.
B1 not committed because not son of latest committed (A2)
B2 not committed because not son of latest committed (A2)
1.126: (B1) updated Italian translation. (B2) fixed a few translation
bugs (C) merge

If the multiple-heads states are not very long (and everyone good
interests is in keeping them short, unless they're doing one of those
rare "revolutions in the source code") the CVS final tree doesn't seem
very unreasonable to me.

What do you think?

(then again, maybe current work by Christof already does this and much
more, in fact I didn't study it properly yet...)

- --
Lapo Luchini
address@hidden (OpenPGP & X.509)
www.lapo.it (Jabber, ICQ, MSN)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJFJ68xAAoJELBiMTth2oCDsnAQALAXCOsdZflzxKDqPBiYWkOM
6FHeJANTOFSQVrF6NGjwVaJ1wIKed4eTDwcudMZ45shFxuQr232Hq2Pq438Bkwi1
u4rbWDxn1ln3X9BZLkmz7T1NauJJzCW0FuAmHA/Vte2JJGUPGWY9HGdnrYLKh71e
F5wQHGzSC6zizqK3Nt/WDc5KfKJ75a69RviipHzYpn9ijrJJEgEcHgLLFkkuw2jZ
HyyvZLA0+rw6AuO6hZUpfr5PFaanADddTYxzKIhvbvrA29x5Oe0bICqBqfe9uNU7
Z+3lE1nNMrflno3Z2lifgq7g5vGZJEDADlSUUHKjQodD9+alInCwKc8T80RT6pvJ
FjOTDfaCxbsbT1sIhCxOb7bqFOZobVzMhBFV5jpCPmp4sZ8Vw1GWrBBuNU9e/Xv/
c/wvfpq7PT/cX3/eHF4FktAP3Tm/xMw0P2AHqsMuTSxzHbNVV4U1XdgKJTbXIYdh
VmtETsW4ncFKvK0zEleTZ1iuaxw0WIFMzbqufkJXkFscqPbvrm/Sh/X/6OT0LnHI
2p5WWjmWQJ8PFhUuz28xt2dspoqIiwDBN7WFzTu/evuox57HIGTBhmhb8mbIJZdR
4qI8+u6k+aZjsY5RAWXTSYSIIpTvD6/s3/Z4E80oKa2EkNkXraZcruyeLbwNyoDv
zYanChwBpMGRwvS/uuQI
=Ri2o
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]