Re: [Monotone-devel] UI to push/pull/sync
In message <[EMAIL PROTECTED]> on Tue, 21 Jun 2005 22:42:27 -0700, Nathaniel
Smith <[EMAIL PROTECTED]> said:
njs> On Tue, Jun 21, 2005 at 08:16:28PM -0600, Derek Scherger wrote:
njs> > I actually kinda liked the early regex code that took an unadorned
njs> > string as a simple collection and a /string/ as a regex. Persumably now
njs> > the unadorned string could be taken as a glob instead of a collection
njs> > prefix.
njs>
njs> /slash/ syntax doesn't seem like it would play well with a
njs> host/project/branch style branch naming scheme?
Neither do the current combined selectors in some cases, so that's a
moot argument.
(BTW, I've played a lot with the host{delim}branch style, and found
the colon to be a pretty good delimiter. venge.net:monotone?)
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
Re: [Monotone-devel] user-defined external mergers...
Vladimir Vukicevic wrote:
On 6/16/05, Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> wrote:
The current idea is that the user can specify commands in the
environment variables MONOTONE_MERGE2 and MONOTONE_MERGE3. They can
contain the following printf-like items:
Hmm, why do things via an environment variable when it's already
possible to set up arbitrary hooks using ~/.monotone/monotonerc or
MT/monotonerc? I think exposing these bits as environment variables
by default really makes it such that you have to expose a lot of other
config via environment variables as well..
I don't agree, i think that it would be very convenient. Just look how
different is to write:
export MONOTONE_MERGE2=something
vs.
function merge3(ancestor, left, right)
local afile = nil
local lfile = nil
local rfile = nil
local outfile = nil
local data = nil
lfile = write_to_temporary_file(left)
... and about 20-30 lines more (yep i know copy and paste), and you must know
Lua at least a little, and if for some magic reason specification of callbacks
would change
then all carefully crafted callback code will become unusable.
Otoh, i don't know Lua and Lua in monotone internals, but maybe following would
good idea.
If Lua supports kind of global variables, then variables such as those
proposed by Richard and many more could be set in rc file as global variables,
so
config would look like this:
merge2_command = "something %x %y %z"
...
and default merge2 callback will use 'merge2_command' variable.
Also, another idea very different to callbacks, but maybe useful for things like
'ignore_file (filename)' callback. How Lua/Monotone. Instead of updating
ignore_file
callback we can modify it to use some internal table of rules, and modify those
rules like this:
add_ignored_files( "/core$" )
add_ignored_files( { "%.a$", "%.o$" } )
or even:
some_global_list_of_ignore_patterns.append( "/core$" )
some_global_list_of_ignore_patterns.append( { "%.a$", "%.o$" } )
Default 'ignore_file' callback would look like this (pseudo code) :
function ignore_file(name)
for each pattern in some_global_list_of_ignore_patterns
if string.find(name, pattern) return true
end
return false
end
And ignore_file(name) would look like that:
Finally going far further "future" configurations would look like those
Workspace:
passphrases.append( "[EMAIL PROTECTED]", "agent would be better idea" )
merge2_command = "mybestmerge2tool %z %y"
merge3_command = "mybestmerge3tool %z %y %z"
Server:
accepted_netsync_write.append( "mycollection", "[EMAIL PROTECTED]" )
passphrases.append( "[EMAIL PROTECTED]", "apart from anything it rulez!" )
Whole issue is how LUA embedded in monotone plays with global variables.
My 2 cents as satisfied, happy monotone user.
DISCLAIMER: i don't know LUA (for now).
--
::: zbigg : Zbigniew Zagórski ::
:: zzbigg (at) o2 (dot) pl ::: GG:5280474 ::
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Merging an ancestor with one of its grandchildren
Zbynek Winkler <[EMAIL PROTECTED]> writes: > Tom Koelman wrote: > >> [snip] >> >>So I ended up committing a trivial change to B, creating B3 and then >>merged Z to B3. This felt really hacky and I don't like this >>solution. Was there a better one? >> >> > I would have done > >monotone propagate NewFeature Main If that's what merge ought to do in that case, then maybe it could just do it, or at least suggest it in the error message. >From what I remember of the code in propagate, at least the latter is likely to be a trivial change; probably the former would be not too hard. In both cases I'd guess the only significant effort is constructing tests. [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Merging an ancestor with one of its grandchildren
Tom Koelman <[EMAIL PROTECTED]> writes: [...] > So I ended up committing a trivial change to B, creating B3 and then > merged Z to B3. This felt really hacky and I don't like this > solution. Was there a better one? Isn't this exactly suitable for propagate? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: key-management problem
Matt Johnston <[EMAIL PROTECTED]> writes: [...] > What do you mean by "dependent certs"? Certificates don't > contribute to the intrinsic "identity" of a revision, so > child revisions won't be affected if you change any certs > of a parent. If you have revisions A -> B -> C, with A and C > signed by Alice, and B signed by Bob, it would be fine for > Alice to duplicate Bob's signatures on B, and optionally > remove Bob's signatures on B. You're right, I think I was confused---one of the changes that happened with changesets is that the structure of the ancestry graph is stable, and no longer depends on whose certs each person happens to trust. I guess partly that feels a bit uncomfortable, in that it's possible to do this: to take a database and entirely replace all the certs, signing them with whatever keys you want. On the other hand, on reflection I'm not sure why that bothered me. So should monotone include some facilities for replacing keys, should someone ever lose their private key, or should someone want to change their name? (It clearly does happen: I happened to just read the message asking what to do after the author had lost their private key.) [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Merging an ancestor with one of its grandchildren
Tom Koelman wrote: [snip] So I ended up committing a trivial change to B, creating B3 and then merged Z to B3. This felt really hacky and I don't like this solution. Was there a better one? I would have done monotone propagate NewFeature Main From the documentation: monotone propagate sourcebranch destbranch This command takes a unique head from sourcebranch and merges it with a unique head of destbranch, using the least common ancestor of the two heads for a 3-way merge. The resulting revision is committed to destbranch. If either sourcebranch or destbranch has multiple heads, propagate aborts, doing nothing. The purpose of propagate is to copy all the changes on sourcebranch, since the last propagate, to destbranch. This command supports the idea of making separate branches for medium-length development activities, such as maintenance branches for stable software releases, trivial bug fix branches, public contribution branches, or branches devoted to the development of a single module within a larger project. Zbynek -- http://zw.matfyz.cz/ http://robotika.cz/ Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Merging an ancestor with one of its grandchildren
Hi, today I was developing and decided to branch off to implement a new feature for my project. In a moment of inspiration I called the branch I split off "NewFeature" while I left the main branch called "Main" alone. After several commits on NewFeature I decided I wanted to merge back to Main. However, in the mean time, no one had committed something on Main so I was in something like this situation: A (Main) | | B (Main) | | + C (NewFeature) | | ... lots of commits | | Z (NewFeature) And I essentially wanted to merge Z and B to branch Main. > monotone explicit_merge Z B Main However monotone complained that B was an ancestor of Z. Is there a fundamental reason why this isn't allowed? A solution that came to my mind was to just give Z a branch certificate called "Main", but if I remember correctly monotone requires branches to be in consecutive commits, otherwise someone still having revision B checked out might think she is at head of Main. Another solution that I thought of was doing an empty commit on main, creating B2 and merging Z with B2. However, monotone doesn't allow me to do an empty commit. Is there a way around this? BTW, why isn't an empty commit allowed? So I ended up committing a trivial change to B, creating B3 and then merged Z to B3. This felt really hacky and I don't like this solution. Was there a better one? Regards, Tom Koelman ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Lost private key
I lost my monotone private key. So what I did is I made a new key with the same name, and dropped the public keys from my other db's. Now it appears monotone is ignoring certs signed with the old key. What is the proper course of action here? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] UI to push/pull/sync
Nathaniel Smith writes: > On Tue, Jun 21, 2005 at 08:16:28PM -0600, Derek Scherger wrote: > > I actually kinda liked the early regex code that took an unadorned > > string as a simple collection and a /string/ as a regex. Persumably now > > the unadorned string could be taken as a glob instead of a collection > > prefix. > > /slash/ syntax doesn't seem like it would play well with a > host/project/branch style branch naming scheme? I liked the suggestion of the glob default, and the use of a --re option to specify that the string is a regex. If we use /slash/ syntax, then using the RE just means escaping the /'s, unless the beginning and trailing slashes are just trimmed off, in which case /usi.hpl.hp.com/monotone/.*/ is a perfectly valid argument, and would select all monotone branches. -Eric ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Boost 1.32 apparently required for monotone head
Just noting this so that the documentation can be updated, in case none of the developers are still using 1.31: 11:24 Hm, I'm trying to build monotone head with boost-1.31, and I'm getting "error: no match for `boost::filesystem::path& < boost::filesystem::path&' operator" from a std::sort in lua.cc. Does monotone require boost-1.32 now, or is this a bug? 11:27 I thought 1.31 was meant to work, though could be wrong 11:28 It did until these changes in lua.cc, AFAIK. 11:29 what function/line? 11:30 I'm not sure, other than something that eventually calls std::partial_sort. I'm not so good at parsing the 100+ line error message. :( 11:31 yeah, looks like 1.32 I guess is required. 11:32 The error is here: http://paste.lisp.org/display/9317 11:32 Okay, I'll upgrade then. 11:32 looking at boost 1.31 here, seems it doesn't have a comparison operator. 11:32 which'd be a problem with sort(), I assume -bcd -- *** Brian Downing ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: tid 539 clobbered tid 482
On Mon, Jun 20, 2005 at 12:12:26PM +0200, Peter Simons wrote: > I'd love to just let this go, but I can't. > > >> monotone: trying 3-way merge > >> monotone: misuse: tid 539 (blast) clobbered tid 482 (blast) > > > > > http://www.loglibrary.com/show_page/view/106?Multiplier=3600&Interval=6&StartTime=1117952588 > > Is there ANY way to fix this problem? Or is there ANY way to > fix the database so that the problem doesn't occur any more? > Is there ANY way I can help to get this problem fixed? Okay, graydon and I looked at this problem again today. Sorry for taking so long. As far as we can tell without looking at your database, you seem to have managed to put two distinct files, that existed in the same revision, on top of each other, and then try to merge that with yet another version. I'm not quite sure how you accomplished this; I know some ways to get such an effect (and they're part of what make our current file identity tracking broken), but they're really quite tricky... I'm very curious :-). Anyway, if that analysis is correct, your tree really is in a strange state, and it just didn't get noticed until now. This makes workarounds a bit tricky. One option is to just comment out the call to ensure_no_rename_clobbers in change_set.cc; I doubt doing so will break things any worse than they already are. Another option is to somehow work around that check; the check is very particular (and thus a bad check, really, there are plenty of similar cases that don't cause problems). For instance, you could rename the file/directory that's causing the problem away on one side, do the merge, and then fix things up by hand. Hopefully the changeset rewrite in the works will clean up all of this mess. -- 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
