From owner-freebsd-doc Sat Mar 18 5:11: 2 2000 Delivered-To: freebsd-doc@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 5C40B37B56C; Sat, 18 Mar 2000 05:10:55 -0800 (PST) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 12WJ0G-000OSI-00; Sat, 18 Mar 2000 15:10:52 +0200 Date: Sat, 18 Mar 2000 15:10:52 +0200 From: Neil Blakey-Milner To: Alexey Zelkin Cc: nik@FreeBSD.org, doc@FreeBSD.org Subject: Re: doc/ tree tagging Message-ID: <20000318151052.A93790@mithrandr.moria.org> References: <20000318120027.A9870@scorpion.crimea.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000318120027.A9870@scorpion.crimea.ua> Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat 2000-03-18 (12:00), Alexey Zelkin wrote: > I remember about attempt of resolving of this problem by creation > of new sgml entities, but it looks little junkly for me. We'll just > create more problems with tracking of documentation for all branches > in that way, IMHO. And add more junk to SGML sources :( Count me against branching the CVS tree for doc/ to the extent I probably won't work on the non-latest version if this happens. It doesn't make sense to have two versions of the documents in our tree, since we'll have a scary split of changes that apply to both branches, or just one branch, and then changes between branches would get out of sync where something previously applied to one branch differently, and where the new change applies to both branches. It'll make our current clean scheme very, very messy. It's perfectly acceptable to have "Before 4.0-RELEASE, the IDE disks were called wd, but since that time, they're now called ad". It also lends a lot of consistency to the reading - someone looking through the FAQ for 3.0 which doesn't mention ad at all, and suddenly walking into it, will be confused. Another interesting spinoff is for those who work across multiple versions, where it makes sense to be presented with "3.0 to 3.3 has 'foo' feature disabled by default, but since 3.4, it is enabled". Why should they read two different versions of a document, and manually have to figure this out? I also think it will be harder for translators to work on a split tree, since they have to track two moving targets now instead of one. They can't just track one, and expect a little playing with diff from the latest target will give them any useful result. Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message