![]() | |||||||||||
Messages in this thread |
Hi! > Now if the development went that way: > > 1.7 -> 1.7.1.1 (branching, i.e. copy) > v v > v 1.7.1.2 > 1.8 v > v -> 1.7.1.3 (merge) > 1.9 v > v v > 1.10 v > v -> 1.7.1.4 (merge) > v v > v 1.7.1.5 > v v > 1.11 <- (merge) > > Pretty much standard, a developper created a new branch, made some > changes in it, synced with mainline, synced with mailine again a > little later, made some new changes and finally folded the branch back > in the mainline. Let's admit the developper changes don't conflict by > themselves with the mainline changes. > > CVS, for all the merges, is going to pick 1.7 as the reference. The > first time, for 1.7.1.3, it's going to work correctly. It will fuse > the 1.7->1.8 patch with the 1.7.1.1->1.7.1.2 patch and apply the > result to 1.7 to get 1.7.1.3. The two patches have no reason to > overlap. 1.7.1.2->1.7.1.3 will essentially be identical to > 1.7->1.8, So, basically, if branch was killed and recreated after each merge from mainline, problem would be solved, right? Pavel -- Horseback riding is like software... ...vgf orggre jura vgf serr. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2005-03-22 13:33 [from the cache] ©2003-2008 | |||||||||||