Ethan Blanton <e...@psg.com> writes: > We have this: > > <toplevel>/ > libpurple/ > pidgin/ > finch/ > libgnt/ > > There are other directories in the branch (and you are correct, I said > 'repository' where I meant 'branch'; I reguarly use three different > DVCSes these days, and the terms start to get fast and loose ;-)), but > they are unimportant here. > > Suppose that we want to be able to release libpurple and libgnt > separately for those who desire, as well as a monolithic repository.
You are implying that "release" means "make a mtn branch available for pull", as opposed to "put a .tar.gz on a webpage"; obviously, there would be no problem with the latter. > We're then going to have: > > <toplevel> > libpurple/ > > <toplevel> > libgnt/ > > <toplevel> > libpurple/ > pidgin/ > finch/ > libgnt/ > > There are two ways to arrive at this; only one is viable given that we > *already have* the example above, but I'll cover them both. > > 1) Break libpurple/ and finch/libgnt/ out into their own branches, and > perform the requisite drops and moves to structure them for > standalone release. We then want to be able to merge changes to > shared files back and forth between the standalone branch and the > monolithic branch. We don't want to have to babysit monotone when > pidgin/gtkmain.c changes and we propagate to the libpurple branch. > I think this is precisely what this thread is about; if I > misunderstand, please correct. We also don't want dies to > propagate from libpurple/ to the monolithic branch; again, we want > to say "no" to that option precisely once, and never see it again > (unless more files are dropped in the future). This requires > complete suspension of die-die-die in both directions, which I > think is what this thread is *working* toward, if it hasn't reached > it already. Ok. That's an interesting use case. I think the proposed 'conflict resolution' attribute could handle this; please think about that. I think a better approach is to provide support in mtn for 'meta-projects', that make handling multiple branches as easy as handling single branches, but that's a different discussion. > 2) Create libpurple, libgnt, and finch/pidgin branches, and suture > libpurple and libgnt into the finch/pidgin branch. This is a different meaning of "suture" than we have been using; this is a "branch suture"; we have been talking about "file suture". >> Would any of the mechanisms proposed in this thread help? >> >> Is some other CM system better? CVS would help, because you can checkout any sub-tree of the repository. But you don't want to go back to CVS just for that :(. > This is the prime question; I don't know. In my empirical experience, > drop + modify becomes painful at some point everywhere I've been. Can you elaborate on how, exactly, it becomes painful? > However, I've never had the opportunity to try a massive drop+modify > restructuring such as described above, so I don't know if things would > eventually smooth themselves out. Right, it is hard to tell without good examples. > I think git probably would. Can you say how? >> An alternate is to live with the 'ignoring upstream changes due to local >> delete' warning in 1.0. >> >> Why is that not ok? > > Two reasons; 1) noisy merges are bad. I agree with that! that's part of the reason I want to promote drop/modified to a conflict. > You really want to tell the user once, let them say "yeah, I really > mean it", and shut up about it. Right. > 2) (and this is a little bit outside of this thread, but I > think closely related) die-die-die prevents cross-propagation of > either this decision or changes to the undead files in one branch. I'm not clear what you mean here. > Now, take all of this Pidgin noise with a grain of salt; we're > actually mid-process of converting our repositories to hg, so while I > think our experience is valuable going forward, our direct needs are > about to be removed from the monotone picture. Unfortunate, especially since it sounds like there might have been a chance to stay with mtn if we had developed a solution to this problem. -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
