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 (obr...@freebsd.org) _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
