Oops, forgot to change the subject..... On 1/4/07, J Decker <[EMAIL PROTECTED]> wrote:
I have recently desired to take my many branches and consolidate them into a larger more co-hesive project such that it may be easier for people to work with. I have used, with much confusion and difficulty, a structure such as work/_MTN (branch1) work/project1/_MTN(branch1.project1) work/project2/_MTN(branch1.project2) work/project1/test1/_MTN(branch1.project1.test1) work/project1/test2/_MTN(branch1.project1.test2) where work contains branches project1 and project 2 as granted by mtn merge_into_dir branch1.project1 branch1 project1 mtn merge_into_dir branch1.project2 branch1 project2 mtn merge_into_dir branch1.project1.test1 branch1.project1 project1/test1 mtn merge_into_dir branch1.project1.test2 branch1.project2 project1/test2 okay that's all ugly, and certainly is not clear... having them all checked out at once, allowing local commits to branch1.project1.test1 which can be propagated to branch1.project1 Okay that's really not workable in the grand scheme... and you end up with 3way merges all over since sometimes the changes within work/project1/test1 would get commited directly into branch1, instead of the correctly merged sub-tree... --------------------------------------------------------- What I did today that failed. (Wish I had some notation here) -> means that a thing was propagated | means that a thing was branched <- means pivot_rooted org.d3x0r.sack | org.d3x0r.sack.plusplus | org.d3x0r.sack.c# org.d3x0r.dekware org.d3x0r.games org.d3x0r.sack -> org.d3x0r.trunk/work/sack org.d3x0r.dekware -> org.d3x0r.trunk /work/dekware org.d3x0r.games -> org.d3x0r.trunk/work/games which then org.d3x0r.trunk becomes a collection of all previosly poritioned out projects, which may now safely depend on each other while still maintaing their own identity. (this is what I wanted I guess in my ideal world) From this state, I can propagate org.d3x0r.trunk -> org.d3x0r.sack or org.d3x0r.dekware and only those files that originated in that branch are propagated. (in reality) org.d3x0r.sack -> org.d3x0r.dekware fails, as both have root nodes that conflict. propagation of org.d3x0r.trunk -> org.d3x0r.sack provides a rename of the root directory to the path provided with the merge_into_dir and dekware and trunk are in sync, and no merge is nessecary. [now org.d3x0r.sack -> org.d3x0r.dekware is possible] This is all so dangerous to do... I don't always want to have the coagulated project, but I would like to propagate changes made there... I suppose I could re-pivot-root delete the old root, commit to a related branch, and propagate that branch back to the original source to get the updates back out correctly... mtn -e pivot_root sack delete; mtn -Re rm delete; mtn commit -m "Updated changes" -b org.d3x0r.trunk.sack mtn propagate org.d3x0r.trunk.sack org.d3x0r.sack but I think that that will cause a great deal of excessive information beyond just a simple merge... I guess all the deleted file entries from the restoration of .sack from .trunk (.trunk.sack), will only exist once... but I do then have to remember org.d3x0r.trunk->org.d3x0r.trunk.sack->org.d3x0r.sack ... the reverse is easy org.d3x0r.sack -> org.d3x0r.trunk
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
