Re: [Monotone-devel] disapprove [...] [FEATURE REQUEST]
On Wed, Jun 01, 2005 at 07:55:35PM -0700, Shaun Jackman wrote: > On 6/1/05, Nathaniel Smith <[EMAIL PROTECTED]> wrote: > > On Wed, Jun 01, 2005 at 01:43:20PM -0700, Shaun Jackman wrote: > > > On the topic of -r, perhaps dissaprove could be modified to use the > > > same syntax as diff, so that... > > > montone disapprove -r -r [...] > > > ... would commit the inverse diff (that the same diff command would > > > have given) as a descendant of . > > > > Hmm, I would have expected that to mean "commit the inverse of the > > diff between and as a child of ", i.e., disapprove > > multiple revisions at once. Which is something people often want. > I think we both mean the same thing. disapprove should also take a log > message. So, my ideal disapprove is... > monotone disapprove -m -r -r [...] Ah, you're right, I just read your message too fast :-) -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] disapprove [...] [FEATURE REQUEST]
On 6/1/05, Nathaniel Smith <[EMAIL PROTECTED]> wrote: > On Wed, Jun 01, 2005 at 01:43:20PM -0700, Shaun Jackman wrote: > > On the topic of -r, perhaps dissaprove could be modified to use the > > same syntax as diff, so that... > > montone disapprove -r -r [...] > > ... would commit the inverse diff (that the same diff command would > > have given) as a descendant of . > > Hmm, I would have expected that to mean "commit the inverse of the > diff between and as a child of ", i.e., disapprove > multiple revisions at once. Which is something people often want. > > -- Nathaniel I think we both mean the same thing. disapprove should also take a log message. So, my ideal disapprove is... monotone disapprove -m -r -r [...] Yeah? Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] disapprove [...] [FEATURE REQUEST]
On Wed, Jun 01, 2005 at 01:43:20PM -0700, Shaun Jackman wrote: > On the topic of -r, perhaps dissaprove could be modified to use the > same syntax as diff, so that... > montone disapprove -r -r [...] > ... would commit the inverse diff (that the same diff command would > have given) as a descendant of . Hmm, I would have expected that to mean "commit the inverse of the diff between and as a child of ", i.e., disapprove multiple revisions at once. Which is something people often want. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: collections are gone; netsync version bumped
On Wed, 2005-06-01 at 17:32 +0200, Peter Simons wrote: > Timothy Brownawell writes: > > > You keep an old version around until the server is > > updated. > > Alright. > > Is there any chance of getting support for "not" matches? So > that I could synchronize all to.cryp.* branches _except_ > to.cryp.foobar by specifying something like this: > > !^to\.cryp\.foobar$ > ^to\.cryp.* The entire string has to be matched, so the ^ and $ are redundant. Meaning, for example, that "monotone" and ".*monotone.*" are entirely different. > I know about [^...] in regular expressions, but that's not > quite the same. We're using boost::regex, which already supports what you want: Forward Lookahead Asserts There are two forms of these; one for positive forward lookahead asserts, and one for negative lookahead asserts: "(?=abc)" matches zero characters only if they are followed by the expression "abc". "(?!abc)" matches zero characters only if they are not followed by the expression "abc". http://www.boost.org/libs/regex/doc/syntax.html So, to\.cryp\.(?!foobar).* is what you want. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook
I'm not against programming, just against making everyone do it. If you can
provide a framework which allows a registry
of common file types against the way of handling them and a library of shipped code fragments which can be incorporated without the
end user having to do any coding, then that would be fine.
Maybe something like:
monotone types filetype --match=\*.xml --type=text/xml<--- Setup initial
default mappings
or
monotone types filetype --file=foo.xml --type=x-rational-xmi <---
Change the type of the file
Then have an object interface like (pseudocode!):
type_handlers {
string[] getSupportedTypePatterns()
void merge3(...args...)
boolean isBinary()
void copyIn(...stream..., ...database..., ..other args)
void copyOut(..destination.., ..database..., ..other args)
etc.
}
A library of type handlers which implemented this type of interface could then be selected at run-time simply by looking up the file
type associated with file, then looking up the handler for that type. Note that there is no reason why these should not be lua if
they are shipped as a standard library.
Whilst I take you point about user preference in merge tools, for many of the 'exotic' types there will be a much more limited set
of merge tools and suppling type variants which are specific to each tool should be feasible.
Thoughts?
Joel
rghetta wrote:
On Wed, 2005-06-01 at 20:07 +0100, Joel Crisp wrote:
I just don't think that it is fair to expect everyone to program what should be
standard functionality in hooks.
Hooks should be there for functionality which is non-standard, e.g. integration with "my" software process rather than
yours...mailing when checkins are done, or enforcing lifecycle constraints.
Choosing how to handle common file types hardly fits into that category, and I think the average user would prefer that to be
supported via a less obscure mechanism.
To give you some comparason: in a recent government job I worked in we weren't allowed to use triggers _at all_ (in clearcase, which
uses perl) on the grounds that no-one else would be able to maintain themlet alone in a language with the limited uptake of lua
(note, I personally think it is ok as a language, but the perception in the industry as a whole is that it is a game programmers
language not a 'commercial' one)
Could you provide some example of an acceptable syntax ?
How you like to specify merging behaviour, how to identify a filetype,
etc.
I really don't see how implement what you want without resorting to some
hook programming, unless we add a built-in filetype identifier.
And even with something like that you need to handle the uncommon
filetype ...
Riccardo
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] disapprove [...] [FEATURE REQUEST]
On 5/30/05, Derek Scherger <[EMAIL PROTECTED]> wrote: > - cert/trusted/tag/testresult/approve/disapprove should use --revision Could disapprove be modified to take an optional list of file names? The result would be to commit the inverse changes of to those files specifically listed as a descendant of the disapproved revision. I'd find this super helpful. On the topic of -r, perhaps dissaprove could be modified to use the same syntax as diff, so that... montone disapprove -r -r [...] ... would commit the inverse diff (that the same diff command would have given) as a descendant of . Cheers! Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook
On Wed, 2005-06-01 at 20:07 +0100, Joel Crisp wrote: > I just don't think that it is fair to expect everyone to program what should > be standard functionality in hooks. > > Hooks should be there for functionality which is non-standard, e.g. > integration with "my" software process rather than > yours...mailing when checkins are done, or enforcing lifecycle constraints. > > Choosing how to handle common file types hardly fits into that category, and > I think the average user would prefer that to be > supported via a less obscure mechanism. > > To give you some comparason: in a recent government job I worked in we > weren't allowed to use triggers _at all_ (in clearcase, which > uses perl) on the grounds that no-one else would be able to maintain > themlet alone in a language with the limited uptake of lua > (note, I personally think it is ok as a language, but the perception in the > industry as a whole is that it is a game programmers > language not a 'commercial' one) Could you provide some example of an acceptable syntax ? How you like to specify merging behaviour, how to identify a filetype, etc. I really don't see how implement what you want without resorting to some hook programming, unless we add a built-in filetype identifier. And even with something like that you need to handle the uncommon filetype ... Riccardo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook
I just don't think that it is fair to expect everyone to program what should be standard functionality in hooks. Hooks should be there for functionality which is non-standard, e.g. integration with "my" software process rather than yours...mailing when checkins are done, or enforcing lifecycle constraints. Choosing how to handle common file types hardly fits into that category, and I think the average user would prefer that to be supported via a less obscure mechanism. To give you some comparason: in a recent government job I worked in we weren't allowed to use triggers _at all_ (in clearcase, which uses perl) on the grounds that no-one else would be able to maintain themlet alone in a language with the limited uptake of lua (note, I personally think it is ok as a language, but the perception in the industry as a whole is that it is a game programmers language not a 'commercial' one) Joel rghetta wrote: Glen Ditchfield wrote: Why can't there be one function that examines the files and decides to run the internal merge algorithm on some kinds of files, and to exec external tools on other kinds of files? Sorry if I'm stating the obvious, but perhaps not everyone is aware that monotone embeds a complete lua interpreter, and you aren't limited to just reimplement the predefined hooks in your monotonerc files. You can also add other functions, tables, etc. For example, you could create a single function to categorize your files, and use it both on the add-time and merge hooks. Something like that: function choose_merge(filename) filedata=read_contents_of_file(name) if filedata ~= nil then if is_word(filedata) return "msword" else * other categorizing code * end end return nil -- filetype unknown end attr_init_functions["manual_merge"] = function(filename) if choose_merge(filename) ~= nil then return "true" -- files with associate tool merge manually else return nil end end function merge3(anc_path, left_path, right_path, merged_path, ancestor, left, right) * common code to setup files (see std_hooks.lua) * ftype = choose_merge(filename) if ftype=="msword" then * call word * else * other tools * end ... end ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook
Glen Ditchfield wrote: > Why can't there be one function that examines the files and decides to run > the > internal merge algorithm on some kinds of files, and to exec external tools > on other kinds of files? Sorry if I'm stating the obvious, but perhaps not everyone is aware that monotone embeds a complete lua interpreter, and you aren't limited to just reimplement the predefined hooks in your monotonerc files. You can also add other functions, tables, etc. For example, you could create a single function to categorize your files, and use it both on the add-time and merge hooks. Something like that: function choose_merge(filename) filedata=read_contents_of_file(name) if filedata ~= nil then if is_word(filedata) return "msword" else * other categorizing code * end end return nil -- filetype unknown end attr_init_functions["manual_merge"] = function(filename) if choose_merge(filename) ~= nil then return "true" -- files with associate tool merge manually else return nil end end function merge3(anc_path, left_path, right_path, merged_path, ancestor, left, right) * common code to setup files (see std_hooks.lua) * ftype = choose_merge(filename) if ftype=="msword" then * call word * else * other tools * end ... end ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: collections are gone; netsync version bumped
In message <[EMAIL PROTECTED]> on Wed, 01 Jun 2005 10:17:49 -0500, Timothy Brownawell <[EMAIL PROTECTED]> said: tbrownaw> You keep an old version around until the server is updated. tbrownaw> (Probably about when the next release is, which AFAIK is tbrownaw> "supposed" to be in a few days.) Hmm, I was thinking of setting up an "experimental" bleeding edge server that would serve as a gateway. I think it might be a good idea... However, if a new release is just a couple of days away, I don't think I'm going to rush ;-). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: collections are gone; netsync version bumped
Timothy Brownawell writes: > You keep an old version around until the server is > updated. Alright. Is there any chance of getting support for "not" matches? So that I could synchronize all to.cryp.* branches _except_ to.cryp.foobar by specifying something like this: !^to\.cryp\.foobar$ ^to\.cryp.*" I know about [^...] in regular expressions, but that's not quite the same. I'm not certain whether I'd really _need_ that feature, but since I intend to abuse Netsync to get rid of branches I don't want any longer, I guess that it would be useful. Peter ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: collections are gone; netsync version bumped
On Wed, 2005-06-01 at 13:07 +0200, Peter Simons wrote: > > This makes netsync incompatible with previously > > How do I update the net.venge.monotone branch now? The > repository at off.net doesn't want to talk to me. Is there > another server? You keep an old version around until the server is updated. (Probably about when the next release is, which AFAIK is "supposed" to be in a few days.) Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: collections are gone; netsync version bumped
Timothy Brownawell writes: > Collections are now completely gone. The syntax for > netsync commands is now "sync regex", rather than "sync > /regex/". Great! That's a feature I've been needing for quite a while; thanks for implementing that. > This makes netsync incompatible with previously How do I update the net.venge.monotone branch now? The repository at off.net doesn't want to talk to me. Is there another server? > For discussion: Should the server now not take any > regexes on the command line, and just serve the entire > database according to what the permissions hooks allow? I wouldn't mind if this change were implemented. Since we have strong cryptography to authenticate who is who and who is allowed to do what, I'd say let's use this mechanism instead of the command line. Peter ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook
Glen Ditchfield wrote: On Tuesday 31 May 2005 00:27, rghetta wrote: Even with the add-time hook you need two functions: one for the add hook, to mark those files you don't want merged by monotone internal algorithm, another for choosing wich merge tool to use. Why can't there be one function that examines the files and decides to run the internal merge algorithm on some kinds of files, and to exec external tools on other kinds of files? Because at add-time you add an attribute to the file, i.e. something wich becomes part of the revision and thus become the same for everyone who syncs with you. At merge time you use this information to choose wich tool to use, i.e. something everyone could handle differently. For example, even on plain text files I use kdiff3 to merge, while others prefer xxdiff, ediff, meld ... In principle we can encode a full filetype as an attribute (perhaps even the mime-type, like subversion), but still you need two functions. One at add-time to choose the filetype, another to invoke the right merge tool. I don't know anything about monotone's internal structure, and I don't want to know, and that's the sort of stuff that changes from release to release anyway. From out here, the internal merge algorithm looks like just one of the possible choices of merge tools. I don't see it as being so conceptually different from other merge tools that it has to be handled by a separate mechanism out at the user-level hook API. The internal merge is different because it represents a fully automated first try. If the internal merge can't resolve cleanly, it needs to escalate the merge to the user, and you want to choose your preferred tool to do this merging. Nothing says you want to use the same tool to handle every file. Besides, "to exec to external tools" you need to call an hook anyway, because every tool wants different options, returns its output differently, and so on. Riccardo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
