[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] mtn:// sync

From: Timothy Brownawell
Subject: Re: [Monotone-devel] mtn:// sync
Date: Wed, 19 Mar 2008 06:58:39 -0500

On Wed, 2008-03-19 at 07:41 +0100, Richard Levitte wrote:
> In message <address@hidden> on Tue, 18 Mar 2008 19:46:46 -0500, Timothy 
> Brownawell <address@hidden> said:
> tbrownaw> I've just added support for mtn:// URLs for push/pull/sync. They 
> look
> tbrownaw> like mtn://server?include&!exclude , I chose this over something 
> like
> tbrownaw> mtn://server/include because it handles include/exclude in a way 
> that
> tbrownaw> should be compatible with file:// and ssh:// sync.
> tbrownaw> 
> tbrownaw> Having a separate include pattern, and the --exclude option, should 
> be
> tbrownaw> redundant now (or fairly soon, after tweaking the other URL scheme
> tbrownaw> handling to accept include/exclude as a query string), so I'm 
> planning
> tbrownaw> to remove these parameters from the netsync commands.
> I suppose this has been thoroughly discussed on IRC.  I haven't
> followed for about two weeks.  

Not really, which is why I posted here before removing things.

> I have no problems with the addition of
> the URL style, but being a die-hard command line nerd, I feel a bit
> rubbed the wrong way seeing the normal command line options go away
> (if that's what you mean).

I'm concerned about sane handling of defaults, since the server/URL is
remembered separately from the include/exclude patterns, and about there
being two places to specify include/exclude patterns. Right now it just
ignores any separate include/exclude arguments if given a mtn:// URL,
and uses "*" if the query string is empty.

I suppose the thing to do would be to take the query string handling out
of the get_netsync_connect_command hook (remove the possibility of also
recognizing URLS like mtn://server/include) and give struct uri a flag
so we can tell the difference between an empty query string and no query
string. Then it could be made smart enough to complain if given both a
query string and include/exclude arguments, but there's still the
question of what to do when neither is provided.

I'd like to treat a missing query string as "*" and not use the
default-{include,exclude}-pattern at all if the server is given as a
URL, since arguably URLs that people might pass around shouldn't change
in meaning based on the recipient's db vars. But then this isn't really
consistent with how the defaults work when the server isn't given as a

reply via email to

[Prev in Thread] Current Thread [Next in Thread]