From owner-freebsd-current@FreeBSD.ORG  Mon Nov  8 09:00:46 2010
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id DB63C1065679;
	Mon,  8 Nov 2010 09:00:46 +0000 (UTC)
	(envelope-from keramida@ceid.upatras.gr)
Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36])
	by mx1.freebsd.org (Postfix) with ESMTP id 3F14F8FC17;
	Mon,  8 Nov 2010 09:00:45 +0000 (UTC)
X-Spam-Status: No
X-Hellug-MailScanner-From: keramida@ceid.upatras.gr
X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0.123, required 5, ALL_TRUSTED -1.00, BAYES_05 -0.50,
	URIBL_SBL 1.62)
X-Hellug-MailScanner: Found to be clean
X-Hellug-MailScanner-ID: oA88o0jo015372
Received: from gkeramidas-glaptop.linux.gr ([74.125.57.34])
	(authenticated bits=0)
	by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id
	oA88o0jo015372
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 8 Nov 2010 10:50:08 +0200
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: current@FreeBSD.org
References: <20101107135329.GL85693@acme.spoerlein.net>
Date: Mon, 08 Nov 2010 09:50:05 +0100
In-Reply-To: <20101107135329.GL85693@acme.spoerlein.net> ("Ulrich
	=?iso-8859-1?Q?Sp=F6rlein=22's?=
	message of "Sun, 7 Nov 2010 14:53:29 +0100")
Message-ID: <xeiaiq08xkqq.fsf@kobe.laptop>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: fanf@FreeBSD.org
Subject: Re: Tricky subversion import, what to do?
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2010 09:00:46 -0000

On Sun, 7 Nov 2010 14:53:29 +0100, Ulrich Sp=F6rlein <uqs@spoerlein.net> wr=
ote:
> Hello,
>
> this is about importing unifdef 2.4, which has no significant code
> changes, but that's not the point. The wiki is of no help for this
> particular case.
>
> We have no exclusive vendor branch for unifdef, instead it has been
> converted to svn under vendor/CSRG/dist/usr.bin/unifdef/ and some
> parts of its history (eg. r1591) are copied from there:
>
>    A /head/usr.bin/unifdef/Makefile (from /vendor/CSRG/dist/usr.bin/unifd=
ef/Makefile:1590)
>    A /head/usr.bin/unifdef/unifdef.1 (from /vendor/CSRG/dist/usr.bin/unif=
def/unifdef.1:1590)
>    A /head/usr.bin/unifdef/unifdef.c (from /vendor/CSRG/dist/usr.bin/unif=
def/unifdef.c:1590)
>
> So, my first instinct would be to
>
> $ svn mv $FSVN/vendor/CSRG/dist/usr.bin/unifdef $FSVN/vendor/unifdef/dist
> (put all files (or just the necessary subset?) of unifdef-2.4 in vendor/u=
nifdef/dist)
> $ svn ci
> $ svn cp $FSVN/vendor/unifdef/dist $FSVN/vendor/unifdef/2.4
> $ svn cp $FSVN/vendor/unifdef/dist/unifdef.{c,1} $FSVN/head/contrib/unifd=
ef/
> $ svn rm head/usr.bin/unifdef/unifdef.{c,1}
> (but this part loses the actual history on head, as it was never
> committed to the vendor branch)
> (update usr.bin/unidef/Makefile to point to contrib/unifdef)
> $ svn ci
>
> But then again, the first steps could also be:
> $ svn cp head/usr.bin/unifdef vendor/unifdef/dist; svn ci
> $ svn cp vendor/unifdef/dist vendor/unifdef/2.3; svn ci
>
> This seems more reasonable to me, but I'm not sure what the policy is on
> "old stuff" under vendor/

I think it all depends on how "valuable" the merge history from
/vendor/CSRG/dist/usr.bin/unifdef to /vendor/unifdef/dist is.  IMO it
isn't, because we won't be merging from the CSRG code anymore.

So I'd prefer the second option.