| From | Sent On | Attachments |
|---|---|---|
| paradox | Mar 4, 2010 5:50 am | |
| Dimitry Andric | Mar 4, 2010 6:47 am | |
| Kevin Oberman | Mar 4, 2010 8:26 am | |
| M. Warner Losh | Mar 4, 2010 9:19 am | |
| Xin LI | Mar 4, 2010 10:35 am | |
| Mark Linimon | Mar 4, 2010 11:12 am | |
| paradox | Mar 4, 2010 11:32 am | |
| Ed Schouten | Mar 4, 2010 12:05 pm | |
| paradox | Mar 4, 2010 12:23 pm | |
| Robert Watson | Mar 5, 2010 1:11 am | |
| Robert Watson | Mar 5, 2010 1:16 am | |
| Poul-Henning Kamp | Mar 5, 2010 1:22 am | |
| Alex Keda | Mar 5, 2010 1:30 am | |
| Robert Watson | Mar 5, 2010 1:41 am | |
| Poul-Henning Kamp | Mar 5, 2010 1:43 am | |
| Doug Rabson | Mar 5, 2010 1:44 am | |
| Poul-Henning Kamp | Mar 5, 2010 1:52 am | |
| Alex Keda | Mar 5, 2010 1:56 am | |
| Doug Rabson | Mar 5, 2010 1:59 am | |
| Mark Linimon | Mar 5, 2010 2:19 am | |
| Alex Keda | Mar 5, 2010 2:47 am | |
| Poul-Henning Kamp | Mar 5, 2010 2:59 am | |
| Svein Skogen (Listmail Account) | Mar 5, 2010 3:01 am | |
| Doug Rabson | Mar 5, 2010 3:03 am | |
| Alex Keda | Mar 5, 2010 3:10 am | |
| Doug Rabson | Mar 5, 2010 3:16 am | |
| Alex Keda | Mar 5, 2010 3:26 am | |
| Poul-Henning Kamp | Mar 5, 2010 3:28 am | |
| Doug Rabson | Mar 5, 2010 3:31 am | |
| Alex Keda | Mar 5, 2010 3:35 am | |
| Dag-Erling Smørgrav | Mar 5, 2010 4:06 am | |
| Dag-Erling Smørgrav | Mar 5, 2010 4:08 am | |
| Alexander Leidinger | Mar 5, 2010 4:20 am | |
| Bernd Walter | Mar 5, 2010 4:51 am | |
| Robert Watson | Mar 5, 2010 5:19 am | |
| Robert Watson | Mar 5, 2010 5:21 am | |
| Robert Watson | Mar 5, 2010 5:23 am | |
| Bruce Simpson | Mar 5, 2010 8:31 am | |
| Julian Elischer | Mar 5, 2010 10:09 am | |
| Garrett Cooper | Mar 6, 2010 1:21 am | |
| Garrett Cooper | Mar 6, 2010 1:28 am | |
| Robert Huff | Mar 6, 2010 6:26 am | |
| David O'Brien | Mar 6, 2010 9:26 pm | |
| David O'Brien | Mar 6, 2010 9:29 pm | |
| David O'Brien | Mar 6, 2010 9:37 pm | |
| David O'Brien | Mar 6, 2010 9:43 pm | |
| Robert Watson | Mar 7, 2010 12:50 pm | |
| M. Warner Losh | Mar 7, 2010 1:47 pm | |
| M. Warner Losh | Mar 7, 2010 1:48 pm | |
| David O'Brien | Mar 7, 2010 4:01 pm | |
| David O'Brien | Mar 7, 2010 4:16 pm | |
| M. Warner Losh | Mar 7, 2010 4:48 pm | |
| Garrett Wollman | Mar 7, 2010 7:29 pm | |
| Garrett Cooper | Mar 7, 2010 10:15 pm | |
| Poul-Henning Kamp | Mar 8, 2010 4:16 am |
| Subject: | Re: propose: all arch move into a separate dir | |
|---|---|---|
| From: | David O'Brien (obr...@FreeBSD.org) | |
| Date: | Mar 7, 2010 4:16:29 pm | |
| List: | org.freebsd.freebsd-current | |
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)
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "free...@freebsd.org"





