Would there be a problem doing an hg push from an mq repository to a non mq one?
Chris Darren J Moffat wrote: > Giorgos Keramidas wrote: > >>> The first of these I see fitting in reasonably well with hg bundle. >>> The second however what I really really want is to be able to revert >>> back to exactly the same point for source code I was in an hour, a day >>> or whatever ago. >>> >> That's where MQ can prove handy. Uncommitted changes in a workspace can >> be saved with: >> >> # hg add foo >> # hg rename bar baz >> # edit some files >> >> hg qnew -f -m 'patch description' newpatch >> hg qcommit -m 'newpatch: save patch state' >> >> Then 'newpatch' appears as an already "pushed" patch, and it can be >> qpop'ed or qpush'ed at will. >> > > I don't think that is anything near as easy to understand as 'wx backup' > 'wx restore' is. MQ just doesn't seem that intuative to me. Also > remember that we have to help those people who have been using teamware > for a very long time and requiring them to use MQ as well as base > mercurial will hurt their productivity for a non trivial amount of time. > > >> The tricky part is making sure that the ~/.hg/patches repository lives >> over NFS or some other place where it has more chance of surviving a >> complete and unrecoverable system crash. Symlinking .hg/patches to an >> NFS-shared location may work, but I haven't experimented with this yet. >> > > If it really is ~/.hg and not .hg in the workspace then that is already > equivalent to 'wx backup' since it uses ~/wx.backup/ > > _______________________________________________ tools-discuss mailing list [email protected]
