monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: a conversation about branching and propagation.


From: J Decker
Subject: [Monotone-devel] Re: a conversation about branching and propagation.
Date: Thu, 4 Jan 2007 22:27:34 -0800

Oops, forgot to change the subject.....

On 1/4/07, J Decker <address@hidden> 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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]