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

On Mon, Jun 20, 2005 at 10:02:59PM -0400, Chris Siebenmann wrote:
> | What BK explicitly guarantees is that if you acquire a set of test
> | data for a node in your change graph, that test data will *always*
> | be valid for that node, no matter what you do to the archive in the
> | future.
> 
>  I don't believe that allowing people to use BK to pull changes without
> their nominal dependencies affects this. 

That's the issue.  I've followed this whole thread and refrained from
commenting until now but that's the whole issue.

If you can show us a way to make your statement be true in way that Eric
(and quite a few other enlightened people) buy it, we're listening.

We know how to do "bad" cherry-picking, it's an easy technical problem to
solve.  What we don't know how to do is to introduce that as a supported
concept in BitKeeper that doesn't remove more problems than it causes.
(Yeah, I know that saying that without explaining it is lame, ping me
and I'll give it a try.  But the bottom line is that shuffling things
around basically amounts to re-writing history and it's wrong, it causes
problems.  In theory it works, in practice it doesn't).

At the risk of being one of the old boring guys I hated at Sun, it's
worth pointing out that we have more insight (being a vendor who talks
to their customers all the time) into what would work and what wouldn't.
You need to understand that the set of people on this list != the set
of BK users.  The people on this list are generally more thoughtful
and aware than the users they support.  The users do not think about
the implications, they think about what they want to do, right now,
implications be damned.  Most of the people here are looking farther
ahead than that and trying to do the right thing for the long term.

Supporting a team of people, even really smart people, who are thinking 
about something else, not SCM, is challenging.  It's a balancing act,
it's not as straight forward as you seem to suggest.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com