Re: [Monotone-devel] usher
On 04/13/2010 07:12 PM, Thomas Keller wrote:
Hi!
I know usher is around for quite a long time now, but I just started
playing with it tonight. One thing I don't quite get is how instance
separation based on pattern matching is supposed to work - imagine you
have these two different setups
server "project-1"
pattern "com.project-1"
local "-d" "/path/to/project-1.mtn"
server "project-2"
pattern "com.project-2"
local "-d" "/path/to/project-2.mtn"
What happens if somebody pulls or pushes changes with "com.project*" or
some other wildcard-using pattern to the server? Would this fail because
neither server would be able to respond? What would happen for a pattern
like "{com.project-1,com.project-2}"?
Both would fail. It looks for servers where the server pattern is an
initial substring of the client's include pattern, and IIRC uses the
matching one with the longest pattern in the case of multiple matches.
What is the status of usher currently anyways? I haven't seen an
official release of it (no tags at least), but it seems to be proven
stable over the last couple of years. If there would be an offical
release, packagers would be able to pick it up easier and could provide
it as tool on top of monotone.
I use a slightly modified version for mtn-host.prjek.net (it gets the
list of servers by listing a directory instead of directly from a config
file), and it seems to work well enough. This also uses only the
hostname to select which server to use, like if you were to only specify
"host" and not "pattern" line in the config file.
The pattern-based dispatch really should be more intelligent I guess,
expand all the braces and make sure all the parts match the same server
(and just make for example having "com" on one server and "com.project"
on another be a config error). I suppose this isn't that big a deal,
might as well just tag current head as a release I guess?
--
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
[Monotone-devel] usher
Hi!
I know usher is around for quite a long time now, but I just started
playing with it tonight. One thing I don't quite get is how instance
separation based on pattern matching is supposed to work - imagine you
have these two different setups
server "project-1"
pattern "com.project-1"
local "-d" "/path/to/project-1.mtn"
server "project-2"
pattern "com.project-2"
local "-d" "/path/to/project-2.mtn"
What happens if somebody pulls or pushes changes with "com.project*" or
some other wildcard-using pattern to the server? Would this fail because
neither server would be able to respond? What would happen for a pattern
like "{com.project-1,com.project-2}"?
What is the status of usher currently anyways? I haven't seen an
official release of it (no tags at least), but it seems to be proven
stable over the last couple of years. If there would be an offical
release, packagers would be able to pick it up easier and could provide
it as tool on top of monotone.
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
Re: [Monotone-devel] the changelog editor branch is ready for review
Derek Scherger writes: > Presumably someone could write a monotone-commit-mode for emacs and > something similar for vim that would allow the editor to prevent you from > editing things you're not supposed to. I take the opposite approach in my Emacs front-end; I edit _MTN/log (almost directly), and tell commit to just use it. That means changing the branch, author etc require separate commands (which I have not implemented). There are commands to enter comment templates from ediff, while reviewing changes. But your approach also makes sense. > I was hoping/expecting to hear from anyone who might be parsing the log > output if they were concerned with the changes being proposed. I've been thinking about implementing 'automate log'; the current log implementation in the Emacs front end is horribly inefficient, and has at least one bug that I'm having a hard time fixing. It uses bunches of automate commands to reproduce approximately what 'mtn log' does. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
