From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 9 10:21:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65F4816A4CE; Fri, 9 Jan 2004 10:21:06 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36E7743D4C; Fri, 9 Jan 2004 10:21:04 -0800 (PST) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id i09IL2HV091406; Fri, 9 Jan 2004 20:21:03 +0200 (EET) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)i09IL237091403; Fri, 9 Jan 2004 20:21:02 +0200 (EET) Date: Fri, 9 Jan 2004 20:21:02 +0200 (EET) From: Narvi To: Lev Serebryakov In-Reply-To: <19210315820.20040109181602@serebryakov.spb.ru> Message-ID: <20040109194720.C32387-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@FreeBSD.org cc: freebsd-chat@FreeBSD.org Subject: Re[3]: Where is FreeBSD going? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 18:21:06 -0000 On Fri, 9 Jan 2004, Lev Serebryakov wrote: > Hello, Narvi! > Friday, January 9, 2004, 4:28:57 PM, you wrote: > > >> DR> 3. Converting the repository. This is a tricky one - I tried the > >> DR> current version of the migration scripts and they barfed and died > >> DR> pretty quickly. Still, I'm pretty sure that the svn developers > >> DR> are planning to fix most of those problems. From mailing-list > >> DR> archives, it appears that they are using our cvs tree as test > >> DR> material for the migration scripts. > >> Did you try my (pure-perl) vatinat ``RefineCVS''? > >> http://lev.serebryakov.spb.ru/refinecvs/refinecvs-0.76.783.tar.gz > >> But, please, read documentation carefully before reporting bugs -- > >> many errors could be avoided with command-line options, sctipy is > >> paranoid by default. > >> Some parts of FreeBSD repository could not be converted, because > >> contains revisions like 1.2.1 and other `I don't know what I should > >> think about this' errors. If you have some good ideas -- let me know > >> :) > N> Huh? Whats wrong with revision 1.2.1 ? This is perfectly normal cvs > N> revision number, even if you have to use a command line option to get it. > N> But it should not require any kind of special treatment. > > It is NOT perfectly normal cvs revision number. WHAT TYPE of > revision number is it? > See, the problem is that you are thinking in overly constrained terms of revision numbers that cvs creates by default, and even so don't think about RCS at all. CVS is not a real CM system its an half-assed one built on top of RCS. 1.2.1 could be a branch (this would be the usual case) or it could be a file revision created by ci(1). in fact, even old (ok, the old here is relative) versions of cvs let you create it as file revision. > Normal numbers are (first level of branching is showed only): > > x.y -- TRUNK > x.y.0.(2n) -- MAGIC for branch (in SYMBOLS only) (2n) here is completely - utterly, totaly, etc - bogus. > x.y.(2n).z -- Revision on branch > x.1.(2n+1) -- Vendor branches (in SYMBOLS only) > x.1.(2n+1).z -- Vendor imports > see above for 2n. > Ok, ok, it should be some broken vendor branch. But what do you say > about `1.1.2'? Or even simple `1' (look into sysintall's Attic). > simple 1 is simple - somebody was using ci, and forgot about dots. 1.1.2 is similar to 1.2.1. > BTW, repo from FreeBSD 4.9 is parsed almost without such errors > (sysinstall, pppd + kernel part of ppp, zoneinfo). > Some problems are with double symbols (one symbolic name marks two > revisions: MAGIC one and simple one), and with symbols, which marks > unexistent revisions (many, many such symbols over all repository). > > But my computer doesn't have enough memory to finish conversion process. > It may be worthwhile to collect such and have somebody do a fixup. > -- > Lev Serebryakov >