Re: [Monotone-devel] Explicit_merge fails with invariant 'I(cs_left == cs_right)' on monotone itself

[Nathaniel Smith]

On Fri, Aug 26, 2005 at 10:23:02AM +0200, Christof Petig wrote:
> I see you working like hell on net.venge.monotone.rewrites.path_handling
> and I have merged my work (for now). Glad to see something done to this
> usability killer (experiencing this more often than once would make me
> look for different VCSs ... even if this has been the only annoyance so
> far). Having several people experience unmergeable trees would kill
> monotones good name for ever. So I was deeply concerned for its future.

Yes, definitely.  Unfortunately, .path_handling is _not_ the actual
fix for this, it's to revamp our path types (file_path, local_path,
fs::path), to get away from boost::fs (a consistent performance
killer) and generally make it harder to introduce certain classes of
bugs (for a trivial example, the bug where you have to pass
project-root-relative pathnames to 'log' even when you are in a
subdirectory is not only fixed, but would be impossible to introduce
in the first place...).

The merging fixes will start as soon as I can get this landed on
mainline; it's an intrusive enough change that I want to get it done
as soon as possible, because it's going to be bad enough to merge as
it is...

The plan for merging is what we're calling "rosters", and based around
my earlier email with subject "file ids".  It's been discussed on IRC:
  
http://www.loglibrary.com/show_page/view/106?StartTime=1124690637&Multiplier=3600&Interval=6
  
http://www.loglibrary.com/show_page/view/106?Multiplier=3600&Interval=6&StartTime=1124773859

I'm very excited about this plan; it should simultaneously improve the
merge situation immensely (both by making it not actually
fundamentally broken, and by giving superior merge results general),
make monotone much faster, and reduce code complexity by an order of
magnitude.

Knock on wood ;-).

> PS: nvm.ssh has a windows capable revision of the _serverless_ sync over
> ssh and sync to a different database (via a pipe to a one time server).
> I'm not overly sold to the syntax (mt sync file:///some.db net.venge*)
> or the code duplication (in serve_single_connection and
> serve_connections). So if you have any suggestions I'll implement it and
> write the documentation once the syntax is sorted out.

I would actually be perfectly happy if netsync started taking urls in
general (netsync://venge.net, ssh://venge.net:~njs/mt.db,
file://~/mt.db?).  There is some precedent...
   
http://web.archive.org/web/20030204063906/http://www.bitkeeper.com/manpages/bk-url-1.html

Dunno if it would make sense to put the pattern in there as well;
perhaps in a # section?  I don't know nearly enough about the funky
details of URL syntax to actually say anything definitive about what
the best way to do any of this would be, unfortunately...

I'll try to look at the code soon.

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff