Best Practices: Keeping the Repository History Understandable

[Evan Jones]

On Jul 22, 2007, at 13:43 , Gregory Collins wrote:
> That's what I do. MQ makes this problem (mostly) go away, although
> things go "wrong" a little more than I'd like (I've become an expert
> "recountdiff" user).

I'll have to play with MQ a bit more so that I really understand it,  
since I don't really get it at the moment. I certainly see how it is  
useful for developing on top of some other project, or useful if I  
need to sling around patches. At the moment it seems to me like if  
everyone I am collaborating with is using mercurial, then the built- 
in push/pull/commit is potentially easier to work with than having to  
track patches.

On Jul 22, 2007, at 15:25 , Mark A. Flacy wrote:
> Why not this?
>
> http://www.selenic.com/mercurial/wiki/index.cgi/ 
> TipsAndTricks#head-5b2e4d05ef883f9b5724f8f1e6d56487545159d3

Hey, that looks like it might be exactly what I want. I'll have to  
try it. If I decide I *do* want to keep the intermediate changes this  
might even let me do that: I would just leave the "dangling" branch  
in the repository, and potentially record it in the changeset  
description for the "combined" change. This might let me have the  
best of both worlds: I can browse "clean" history, but if I wanted  
to, I could see the dirty details about how the change evolved. Thanks!

Evan

--
Evan Jones
http://evanjones.ca/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20070722/644b73c7/attachment.htm