Re: Re: Maintaining 'stable' and 'development' versionsof a repository (hopeless newbie question)

[I guess you may have meant to reply to the list. Apologies if you didn't.]

Chris Siebenmann wrote:

>  My personal opinion is that this is somewhat like putting people
> in straightjackets to keep them from scratching their poison ivy
> rashes. It's guaranteed to work, but ...

I like things that are guaranteed to work, better than things that are 
not guaranteed to work. At least then I know where I stand ;)

It will be interesting to see how future versions of BK deal with this. 
I suspect we'll just have a cleaner interface for moving changesets 
around, but changesets applied in a different order from a given common 
ancestor will have different changeset keys even though they have the 
same content.

> (Of course to go for some lesser measure of dependency requires
>  either semantic knowledge of the repository content or using
>  imperfect mechanistic checks, like 'changes different files'.

My intuition is yelling "nooooooooooooo!". Sounds a bit messy.

>  But people do keep making and making this mistake, so clearly
>  it's human nature to work this way.)

Often, though, things are counterintuitive as with this example. It 
would be nice to bend reality to work with the expectations of human 
nature though :)

You are right, that it seems to be human nature to assume that it works 
this way. I've done a few presentations involving BK and usually bring 
up revtool. Invariably after explaining the graph, I get the question 
"what if you want to grab that one and that one, but not that one?".