Re: propose: all arch move into a separate dir

On Sun, Mar 07, 2010 at 08:51:22PM +0000, Robert Watson wrote:
> On Sat, 6 Mar 2010, David O'Brien wrote:
>> No, not it isn't.  Provide a script to convert path's in the diff. This is 
>> what $LARGE_FREEBSD_USER did when it rearranged it source tree.
>> 
>> It was done by creating a copy of the CVS repo and moved files around. Old 
>> releases stayed in the old repo, and new releases done from the new repo. 
>> 'diff | fixpatch | patch -p0' were used to move code between sandboxes.
> 
> Indeed, this is precisely the problem: rearranging the tree upstream means 
> that you most likely can't use the revision control system to manage your 
> local difference set downstream.

It does not mean downstream users cannot their revision control system
manage changes - it only means those using CVS cannot easily.

Lets say I'm a 3rd party based on FreeBSD.  One "vendor imports" the
FreeBSD sources for what ever version they are based on.  When new
FreeBSD version comes out with 'sys/arch/' that would be reflected in
the SCM on that vendor branch.  The SCM would track that directories
moved.

Now when the new FreeBSD import was merged into the working sources
branch, the SCM would track that the directory moves would need to
happen there also.

Done deal.


> Instead, you have to manually extract 
> your local changes, rework them to match arbitrary upstream rearrangement, 
> and re-apply them as a single changeset creating a discontinuity in your 
> revision history.

No, you could use the SCM to do it.  All modern SCM's that I'm familiar
with track directory moves.  Resulting in a situation where there is not
lossage with "log", "blame", etc..

I am speaking as one of the downstream users of FreeBSD - $WORK could
consume such a move - so please don't hold them up as a reason to not
consider moving the CPU directories under arch/.

I know of two 3rd parties with product based on FreeBSD - one uses
subversion, and the other uses Perforce.  Granted I don't know what
the others use - but we could query them.


> However, other downstream users (including our 
> own development branches in Subversion, P4, etc) reasonably expect to
> be able to use contemporary tools to manage the merge on a more
> frequent basis.

Yes - have you had a bad experience with merging such changes from HEAD
to a project branch in our own subversion tree?

My experience is, given a HEADS UP to a directory move, it is not hard
to handle merges in subversion.

-- 
-- David  (obrien_at_FreeBSD.org)