On Fri, Jan 14, 2011 at 2:41 PM, Richard Hipp <d...@sqlite.org> wrote:
> I'll try to improve the situation moving forward. But to be honest, right > now I'm having a hard time trying to figure out what it should be doing in a > lot of these scenarios. > Indeed, a 'revert' put me back into a working state :). My assumption was that this particular constellation of actions is associated with a big fat can of worms and difficult philosophical questions, but i was hoping you had already answered them during the implementation ;). i'm not surprised that there are still-open corner cases with this mix of commands. Here's a thought: Perhaps instead of disallowing all updates if there is an > uncommitted merge, perhaps only disallow updates to other branches. So if > you do a merge, you can still update to descendents (thus pulling in > changes that others have committed ahead of you). Such a feature would have > kept you out of trouble in the first place, in the scenario above.... > If you think that will work. i'm pretty clueless when it comes to the details of artifact tracking, and can't offer any helpful suggestions. Thanks for the 'revert' tip - that did the trick. -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
