[Monotone-devel] [bug #20898] Strange errors when out of disk space

2010-04-27 Thread Thomas Keller

Update of bug #20898 (project monotone):

  Status:None => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


[Monotone-devel] Re: [bug #20898] Strange errors when out of disk space

2010-04-27 Thread Thomas Keller
Am 27.04.2010 09:15, schrieb Thomas Keller:
> 
> Update of bug #20898 (project monotone):
> 
>   Status:None => Fixed  
>  Open/Closed:Open => Closed 

Btw... this still counts for you :)

Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en




signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


[Monotone-devel] [bug #29677] mtn log crashes if wrong database is specified

2010-04-27 Thread Thomas Keller

Update of bug #29677 (project monotone):

  Status:None => Fixed  
 Assigned to:None => tommyd 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

The patch has been committed as 17de04cde8aaaff47f17927965130fd721d16ac6.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


[Monotone-devel] [bug #28372] mtn git_export doesn't specify an "author name"

2010-04-27 Thread Thomas Keller

Update of bug #28372 (project monotone):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

This has been fixed in 280779a51cbfc28b7c59f8fe84dd084035febb5d (0.47)

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


[Monotone-devel] [bug #7220] [NEED TEST] Monotone handles deleted files very ungracefully

2010-04-27 Thread Jack Lloyd

Follow-up Comment #3, bug #7220 (project monotone):


This seems to behave as it should in 0.47:

(motoko ~/test)$ rm -f foo
(motoko ~/test)$ mtn stat .
mtn: warning: missing file 'foo'
mtn: misuse: 1 missing items; use 'mtn ls missing' to view
mtn: misuse: To restore consistency, on each missing item run either
mtn: misuse:  'mtn drop ITEM' to remove it permanently, or
mtn: misuse:  'mtn revert ITEM' to restore it.
mtn: misuse: To handle all at once, simply use
mtn: misuse:  'mtn drop --missing' or

And dropping a file that was previously deleted is also handled nicely.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


[Monotone-devel] Re: netsync connection info cleanup

2010-04-27 Thread Timothy Brownawell

On 04/18/2010 01:49 PM, Thomas Keller wrote:


The following URIs are currently supported:

  mtn://monotone.ca
  mtn://monotone.ca/monotone
  mtn://monotone.ca?foo.bar
  mtn://monotone.ca?foo.bar*/-foo.bar.baz
  mtn://monotone.ca/monotone?foo.bar
  mtn://monotone.ca/monotone?foo.bar*/-foo.bar.baz
  mtn://monotone.ca?include=foo.bar
  mtn://monotone.ca?include=foo.bar*/exclude=foo.bar.baz
  mtn://monotone.ca/monotone?include=foo.bar
  mtn://monotone.ca/monotone?include=foo.bar*/exclude=foo.bar.baz

The first unfortunate thing here is that we have to support two
different syntaxes, one time you can omit "include=" and replace
"exclude=" with a "-" and one time these can be given (probably because
we advertise that people could use weird branch name patterns which
don't follow the reverse dns scheme almost everybody uses, but this
doesn't seem to work correct either, try f.e.
"mtn://monotone.ca/monotone?include=foo/bar/baz*/exclude=foo/bar/baz/bla").

The second unfortunate thing is that the "short" syntax, while being
less verbose, still needs quoting because of "?" as the query separator
and "*" for branch expansion.


So how should we continue? I think we should pick _one_ syntax and stick
to that, and I'd vote for the simple one

mtn://monotone.ca?foo.bar*/-foo.bar.baz


Seems reasonable.


but with a few modifications so it would look like this:

mtn://monotone.ca/foo.bar%/-foo.bar.baz

(or explicitely mtn://monotone.ca/+foo.bar%/-foo.bar.baz)

Here no comand line quoting is needed at all and the SQL-like "%"
wildcard should be recognizable as well.


Is the occasional backslash really that bad? '%' conflicts with 
urlencoding (and '*' would only actually glob things if you have some 
really weirdly named files), and '?' is probably necessary for file/ssh 
sync.



Secondly, I'd actively deprecate any branch name which does not match
the following regular expression, i.e. by throwing a warning when a
branch cert which a different value is created:

^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$

(test script to play around: http://pastebin.ca/1866605)

This way we ensure that a branch name later does not conflict with the
URI separator nor with the wildcard character nor with the negation we
need for branch exclusion in our URI scheme.


I like this.


Thirdly I'd unify the way includes and excludes are defined for netsync
commands. I'd deprecate the "SERVER BRANCH [--exclude=PATTERN [...]]"
options (but would leave them available and convert them to the internal
representation with "%" as wildcard f.e.) and I'd make the new URI
available for all commands (currently clone does not support the old
URIs f.e.).


Sounds good.


Lastly, the only thing which has not yet been determined is how we can
represent the server notion for usher - clearly this would conflict with
the new branch pattern, ie. does

mtn://monotone.ca/monotone/net.venge.monotone

mean

a) server instance monotone, branch net.venge.monotone - or
b) default server instance, branches monotone and net.venge.monotone

I can think of several solutions:

1) "misuse" the user part of the url, ie. mtn://monot...@monotone.ca/...


Don't we use the user part properly already for ssh sync?


2) make the server part mandatory and the first part of the path, ie.
mtn://monotone.ca/monotone (or mtn://monotone.ca// or
mtn://monotone.ca/default or whatever)


I don't think logic relying on this would play nicely with file/ssh 
sync, where there can be any number of path components.



3) use a special character to denote the server instance, f.e.
mtn://monotone.ca/~monotone/...


This could work except for our interpreting '~' in file/ssh sync.

4) require a '+' before the inlcude patterns (as shown in your
   later examples). Yeah '+' is used in place of ' ' in URLs, but
   we'd be deprecating use of spaces in branch names anyway.


Finally, how do other URIs (not based on the mtn:// protocole look like?
Well, I'd probably simply append them on the original one, like so:

file:///path/to/db.mtn/+branch/-branch - and
ssh://server/~/db.mtn/+branch/-branch - or
ssh://server/path/to/remote/db.mtn/+branch/-branch


It looks like a path, but it isn't (entirely) a path. That seems 
horribly counterintuitive and a rather bad idea.


I suppose any '+' in the actual filename would have to be urlencoded (to 
not be taken as a space) and spaces can be done as '%20' as well as '+', 
so it's really only very slightly ambiguous unless someone puts the 
exclude pattern first, but still the lack of clear separation between 
"what we're talking to" and "what we're talking about" is a bit 
disconcerting.


--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] Re: netsync connection info cleanup

2010-04-27 Thread Zack Weinberg
On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell  wrote:
>
> Is the occasional backslash really that bad? '%' conflicts with urlencoding
> (and '*' would only actually glob things if you have some really weirdly
> named files), and '?' is probably necessary for file/ssh sync.

I think it's more important to avoid characters that are meaningful in
URLs (*especially* %) than to avoid characters that are meaningful to
the shell.  People expect to have to quote URLs.  Also, I don't like /
as a separator when it's not traversing a directory-like hierarchy.

So, how about this?

  
protocol://u...@server.host.name/path/to/database?include,include,-exclude,-exclude

should work equally well for mtn (with usher), ssh, and file.  Without
usher, you just leave out the /path part.

(Also, ~ in the path part should absolutely have the 'go to home
directory' semantic.)

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] Re: netsync connection info cleanup

2010-04-27 Thread Timothy Brownawell

On 04/27/2010 06:54 PM, Zack Weinberg wrote:

On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell  wrote:


Is the occasional backslash really that bad? '%' conflicts with urlencoding
(and '*' would only actually glob things if you have some really weirdly
named files), and '?' is probably necessary for file/ssh sync.


I think it's more important to avoid characters that are meaningful in
URLs (*especially* %) than to avoid characters that are meaningful to
the shell.  People expect to have to quote URLs.  Also, I don't like /
as a separator when it's not traversing a directory-like hierarchy.


Huh, hadn't really considered the "overloading '/'" aspect. It does seem 
slightly bad now that you mention it.



So, how about this?

   
protocol://u...@server.host.name/path/to/database?include,include,-exclude,-exclude


+1


should work equally well for mtn (with usher), ssh, and file.  Without
usher, you just leave out the /path part.

(Also, ~ in the path part should absolutely have the 'go to home
directory' semantic.)

zw



--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] Re: netsync connection info cleanup

2010-04-27 Thread Derek Scherger
On Tue, Apr 27, 2010 at 5:54 PM, Zack Weinberg  wrote:

> On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell 
> wrote:
> >
> > Is the occasional backslash really that bad? '%' conflicts with
> urlencoding
> > (and '*' would only actually glob things if you have some really weirdly
> > named files), and '?' is probably necessary for file/ssh sync.
>
> I think it's more important to avoid characters that are meaningful in
> URLs (*especially* %) than to avoid characters that are meaningful to
> the shell.  People expect to have to quote URLs.  Also, I don't like /
> as a separator when it's not traversing a directory-like hierarchy.
>

Agreed, on all counts.


> So, how about this?
>
>  protocol://
> u...@server.host.name/path/to/database?include,include,-exclude,-exclude
>
> should work equally well for mtn (with usher), ssh, and file.  Without
> usher, you just leave out the /path part.
>

+1 (nice and simple)


>
> (Also, ~ in the path part should absolutely have the 'go to home
> directory' semantic.)
>

Agreed here too.

This proposal doesn't change the meaning of any URL-special characters which
I think is important. Overloading % + ? = or & would be bad as people
generally know what they mean in the context of a URL. We could consider
using the fragment character # in place of the query string separator
character ? but that's probably splitting hairs. This is a shell-special
character too (for comments) but it doesn't seem to apply if there's
non-whitespace immediately preceding it.

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel