>>>>> "Bruce" == Bruce Stephens <[EMAIL PROTECTED]> writes:
Bruce> I'm not particularly bothered about keeping redundant work
Bruce> (which in git could vanish); I am worried about ending up
Bruce> with zillions of branches which have names we no longer
Bruce> like and which were only of relevance for a few days
Bruce> anyway. And should we not use branches so much, I worry
Bruce> about ending up with experimental forks where someone's
Bruce> deleted files, which then just get in the way.
Same here. Things change. Maybe calling a branch x.y.z.Feature_X is no
longer appropriate, as decision was made that this was a bad way to
implement Feature X, but an excellent way of implementing Feature_Y
instead.
The new and rewritten Feature_X might go into a branch called
x.y.z.Feature_X.2, x.y.z.Feature_X might turn into x.y.z.Feature_Y,
and people continue to get confused over this obsolete x.y.z.Feature_X
branch.
Oh maybe, management decide it is no longer politically correct to
call it Feature_X but Feature_Better_X or something instead.
Bruce> (I agree that policy branches may well solve all these
Bruce> issues---that's certainly the kind of thing they're aimed
Bruce> at making possible. But I think we want to change soonish,
Bruce> and I don't see policy branches being usable in the
As there any references on how policy branches will solve these
problems?
Bruce> relevant timescale. (I'm currently not considering
Bruce> mercurial because git's MinGW port seems OK, and because I
Bruce> don't have a clear understanding of mercurial's local
Bruce> branches: they look a bit too new, and not enough like
Bruce> git's nicely simple idea.))
How does mercurial cope?
--
Brian May <[EMAIL PROTECTED]>
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
