Re: [Monotone-devel] monotone automate stdio

[Joel Crisp]

Hi
Just a small comment; maybe a format using the numeric prefix familiar to us 
all from RFCs like
200 OK UNKNOWN test/foo
201 foo.h
201 foo.c
etc.
This format is more likely to be parsable with existing libraries and is 
familiar to people who have worked with other
software.
Joel
Timothy Brownawell wrote:
There've been some requests for a way to run multiple automate commands
without needing a new monotone process for each. There's now a new
command, "monotone automate stdio" that takes automate commands on
stdin. Currently, it prefixes the output of each command with the line
"###BEGIN ###" and follows it with one of
"###END ###", "###ERR  usage###", or
"###ERR  msg ###" depending on whether the command was
successful, was invalid, or encountered some other error.
Tim

___
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] monotone automate stdio

[Grahame Bowland]

Timothy Brownawell wrote:
There've been some requests for a way to run multiple automate commands
without needing a new monotone process for each. There's now a new
command, "monotone automate stdio" that takes automate commands on
stdin. Currently, it prefixes the output of each command with the line
"###BEGIN ###" and follows it with one of
"###END ###", "###ERR  usage###", or
"###ERR  msg ###" depending on whether the command was
successful, was invalid, or encountered some other error.
Awesome :-) The one thing I'd really like to be do many times is 
retrieve the certs associated with a particular revision. In order for 
this to be possible, a command equivalent to "monotone ls certs" would 
need to be available in an automate command.

Does anyone have any objection to such a command being added? Could 
"monotone ls certs" just be changed to "monotone automate certs"?


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

Re: [Monotone-devel] Re: 3-way merge considered harmful

[Oren Ben-Kiki]

On Friday 13 May 2005 07:18, Nathaniel Smith wrote:
> Another option is to use something like codeville-merge, in which a
> version is defined by its state, but its state includes information
> on "how it got that way".

Right. That's a variant along the way to a full Darcs-like system.

> ... A common developer intent is, "take
> everything new in this side and everything new on that side and smush
> them together to make something that has both".
>
> And in this phrasing, my argument is that there is, in general, no
> ancestor that expresses that intent.

"This side" and "that side" refer to some known point, otherwise they 
are meaningless - which is exactly the problem. So I completely agree 
that if all you have is the topology, and you are given _only_ the ids 
of two revisions to merge, in general there's no way of automatically 
computing this base point:

> > Certainly the system can compute the correct ancestor for a
> > particular intent, such as merging a branch back to the main trunk
> > etc. However, I suspect that any such algorithm must, to some
> > extent, rely on meta-information that is not available in the
> > topology itself (call this the expected development "workflow").

Monotone (like many other "new" systems) walks along the thin line 
between being completely workflow agnostic - which is great in theory, 
but in practice makes it impossible to provide many very useful 
operations; and enforcing a specific workflow, in which case you can 
provide all imaginable useful commands - as long as you follow that 
specific workflow. Git and Aegis are good examples close to the end 
points of this spectrum.

Ideally, Monotone would use a layered approach. At the "workflow 
agnostic" level, monotone should allow a 3-way merge that would require 
all three revisions to be specified. Then, in a "workflow aware" level, 
it is possible to provide algorithms that compute the correct ancestor 
for common intent. You can't have it both ways - being "workflow 
agnostic" and computing merge ancestors.

This means that some commands would simply not be available in the lower 
level. A clear-cut example is "pass review" - not all workflows even 
have the concept of a version state which includes formal reviews. If 
there was an easy way to create workflows on top of a basic layer 
(using Lua hooks or shell scripts or whatever), then issues such as 
computing the best merge ancestors for various intents would naturally 
belong there.

> The problem is that people really do want to create arbitrary graph
> topologies.

As long as monotone is not going to provide an explicit "workflow" 
concept, I think that providing a default simple least-common-ancestor 
algorithm would probably find the right ancestor in most cases. It is 
important that the algorithm will detect when the DAG is too complex 
for the result to "make sense", and in this case it would require the 
user to provide the base revision manually (this should always be an 
option). For extra credit, allow dry-running it, and maybe even print a 
list of likely candidates in case of a complex DAG.

> ... Certainly, having a solution that works for arbitrary DAGs is
> much more confidence inspiring than having a bunch of different
> solutions that only work in particular special cases, and then just
> hoping that no non-special cases ever show up.

The thing is, using a particular workflow, one _knows_ that only 
particular special cases will ever arise, and it makes perfect sense to 
use a simple algorithm tailored to that workflow/special cases...

Have fun,

Oren Ben-Kiki


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

[Monotone-devel] Bitkeeper -> Monotone?

[Peter B. West]

I have an XSL-FO implementation project, Folio, hosted on bkbits.net.  I 
need to find another SCM, and another host. Approximate current size of 
the project is 2500 files totalling 25Mb, which includes jar files of 
required ant, xalan and xerces binaries.  Final size should not exceed 
3500 files and 40Mb.  The self-hosting web-page says:

If you have difficulty setting up a server, or are feeling lazy and 
would like us to host one for you, send an email to the list. For 
projects of a reasonable size, or if you just want to play around, we'd 
be happy to host an extra server for you.

Unfortunately I don't have a static IP, so I am looking for a looking 
for a stable host.  Can you do this for me?

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

[Monotone-devel] [Fwd: never two without three: the %+ specifier]

[Emile Snyder]

-Forwarded Message-
From: rghetta <[EMAIL PROTECTED]>
To: Emile Snyder <[EMAIL PROTECTED]>
Subject: never two without three:  the %+ specifier
Date: 16 May 2005 17:12:41 +0200

Ahem. 
Here comes another patch (I hope you don't get upset by this endless
stream) :)
This patch add a %+ specifier, to handle a multi-column formatting.
Currently you can't alternate format strings to obtain something like
 
 
Instead you must apply the same fmt string to all rev's.  The %+
specifier divides the format string into regions. 
The first region is applied to the first rev, the second region to the
second rev, and so on. When the regions terminate, the cycle begins
again.
 
Consider as an example two commits, one by [EMAIL PROTECTED] and one
by [EMAIL PROTECTED]

The format string '%a\n' will give you
[EMAIL PROTECTED]
[EMAIL PROTECTED]

The format string '%a %a\n' will give you
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]

just repeating the author, where '%a %+ %a\n' gives instead
[EMAIL PROTECTED]  [EMAIL PROTECTED]

The %+ applies only to the main fmt string, I'm considering if and how
apply that to the changeset strings.
What do you think ?

Anyway, here's the changelog:

*format.cc, format.hh: add the new %+ format specifier
*monotone.1, monotone.texi: document it

Riccardo




+--
RFC1925: "With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead." 
+--
# 
# patch "format.cc"
#  from [89c8a712b18ef4b392a00244087be07a2678c7a6]
#to [84e3fc07c09bd99df48e9c8da948b20fe4715a96]
# 
# patch "format.hh"
#  from [e2060fde3c8635c17e1c3d0cb164cebd6bfba6b2]
#to [c5d8038ca6a05a784badf2fba25f08ec0975b787]
# 
# patch "monotone.1"
#  from [b4333b9f17ba604ca732d3de2e833c78bf0991a7]
#to [2f053fc3c1b544dc2cfd523d443a4968966b721c]
# 
# patch "monotone.texi"
#  from [4ec8f99151eb98cd9058d5afaa31dd94fd4c2166]
#to [1cd3647b4cc2c03fc45c6abfe8072a6ada288f8e]
# 
--- format.cc
+++ format.cc
@@ -102,6 +102,9 @@
   // final string  
   buf.assign(start_current_fmt, i);
   fmtstrs[current_fmt] = utf8(buf);
+
+  // assign the starting point for apply()
+  startpoint = fmtstrs[FMTIDX_REVISION]().begin ();
 }
 
 
@@ -349,7 +352,7 @@
   app.db.get_revision_certs (rid, certs);
   erase_bogus_certs (certs, app);
 
-  std::string::const_iterator i = fmtstrs[FMTIDX_REVISION]().begin ();
+  std::string::const_iterator i = startpoint;
   std::string::const_iterator e = fmtstrs[FMTIDX_REVISION]().end();
   while (i != e)
 {
@@ -405,6 +408,11 @@
   else
 out << rid.inner()();
   break;
+case '+':
+  N(!short_form, F("no short form for the '%%+' formatting 
specifier"));
+  startpoint = ++i; // predispone next starting point
+  N(startpoint != e, F("A format string can't terminate with 
'%%+'"));
+  return; // exit directly from the function, skipping the rest
 default:
   N(!short_form, F("no short form for changelog specifier"));
   // unrecognized specifier, perhaps is a changeset one ?
@@ -418,6 +426,9 @@
   
   ++i;
 }
+
+// resets fmt str starting point
+startpoint = fmtstrs[FMTIDX_REVISION]().begin ();
 }
 
 
--- format.hh
+++ format.hh
@@ -80,6 +80,7 @@
 private:
   std::ostream & out; 
   utf8 fmtstrs[8];  
+  std::string::const_iterator startpoint;
 };
 
 
--- monotone.1
+++ monotone.1
@@ -328,7 +328,11 @@
 %m  : manifest id
 .br
 %sm : shortened manifest id
+.br
+%+  : terminates formatting for the current revision. The next revision
+will be formatted by the specifiers following %+
 
+
 The short forms have the following meanings:  For author, everything 
 before the first @ symbol.  For branch, everything after the last '.' 
 character.  For date, everything before the first 'T' character.  
@@ -360,6 +364,15 @@
 , \\% and \\@ are used to obtain the \\, % and @ char respectively.
 
 The default format string is '%i\\n'. 
+
+The specifier %+ is used to apply alternating format strings to
+different revisions. When found, a %+ specifiers terminates the
+formatting of current revision.
+The next revision to be formatted will 'see' only the format string
+following the %s.
+To have a two column author output you will use a '%a %+ %a\\n' format
+string.
+
 .TP
 \fB--xml\fP
 Generate an xml document based on automate output and containing full
--- monotone.texi
+++ monotone.texi
@@ -4875,6 +4875,8 @@
 %r : value of testresult certificate
 %t : value of tag certificate
 %[s]m : manifest id
+%+ : terminates formatting for the current revision. The next revision
+will be formatted by the 

Re: [Monotone-devel] monotone update overwrites local changes

[Emile Snyder]

On Sat, 2005-05-14 at 21:21, Derek Scherger wrote:
> it seems to me that there are three settings for such a hook
> 
> - fail on pre-existing files
>   (cvs, svn, etc. do this)
> 
> - preserve pre-existing files but continue
>   (which I think would be useful occasionally)
> 
> - clobber pre-existing files
>   (what monotone does now)

I'd like door number 4: move pre-existing files out of the way (foo ->
foo.bak.revid maybe?) and continue.

thanks,
-emile

> fail and clobber seem like the extremes and preserve seems like it might
> actually be a nice compromise.
> 
> Cheers,
> Derek
> 
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel

+--
flailover systems: when one goes down, it flails about until the other
goes down with it. -- Rodger Donaldson 
+--



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

[Monotone-devel] Projects using monotone?

[Richard Levitte - VMS Whacker]

I have been thinking of finally moving some of my CVS-managed projects
to monotone.  For one of them, I was asked what other projects are
using monotone, as some kind of "proof of maturity" (I know, it's not
regarded as mature enough for production according to some.  I don't
entirely agree).

So, I'd like to know, what other projects are using monotone?  And
don't restrict yourself to free software projects.

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] Test message

[Peter B. West]

Sorry about this, but i got nothing back from my subscribe attempt.
--
Peter B. West 
Folio  
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone update overwrites local changes

[Nathaniel Smith]

On Sat, May 14, 2005 at 10:21:32PM -0600, Derek Scherger wrote:
> Nathaniel Smith wrote:
> > On Wed, May 11, 2005 at 08:47:56PM -0600, Derek Scherger wrote:
> >>How about just skip the file and keep going, perhaps with a warning like
> >>"preserving existing file ...".
> > 
> > This violates "refuse the temptation to guess".
> > 
> > I suggest, check for such files; if they exist, tell the user what's
   
> > up and refuse to go on.  Then the user can investigate and take
> 
> at which point half of my tree has been updated. I now have an old value
> in MT/revision, no idea what changes have been applied and no record of
> what revision those changes came from.

Yeah, we have to check before we irrevocably commit to modifying
things.  Shouldn't be any harder than checking after we do that;
probably is easier, even.

> I'm not sure I agree with the "refuse the temptation to guess" assesment
> either. if I've set a hook to say, don't update pre-existing files but
> don't quit either, then there's no guessing involved.

No, there isn't; there're separate questions of "what the default is",
and "what other options could the user could override that with".
"refuse the temptation to guess" only speaks to the first question,
but I think it's pretty compelling there.

So, configurability... we should generally remember that just because
we _can_ make something configurable, doesn't mean we _should_ :-).  I
don't really see the point of having a "clobber existing files" mode;
you would never want to make it the default, and in any case where you
actually wanted it, it would be just as easy to delete the existing
files as to signal your intent some other way (modify a hook, etc.).
Maybe for the preservation mode it would be useful to have some sort
of support, but again, whenever this case comes up, you want to do
some manual inspection to figure out what's going on anyway, so having
the non-configurable default be to basically tell the user "hey, you
need to do something manual here", still seems fine.  Maybe a
subcommand option on update to preserve existing files would be good?

Implementing "fail before clobber" is clearly an incremental win over
our current behavior, and the subcommand thing could be a separate
change, after that was working.

-- 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

[Monotone-devel] [patch]--depth for monotone ls

[Joel Reed]

I took a look at adding support for limiting monotone's recursive
predilections, which seems to be important option for some. I need
it for better zsh file completion. Anyway I was able to add it in
suprisingly few (to me at least) # of lines. 

I used --depth=X as the option and tested the code by adding it to
"ls known".

X above is used as a mechanism to indicate how many times the restrictions
code in app_state.cc:restriction_includes may do a branch_path to walk up
the directory tree.

Thus for a tree:

./a
./a/b
./a/b/c
./a/b/c/d
./a/b/c/d/file
./a/b/c/file
./a/b/file
./a/file
./file

(%:~/tmp/root) monotone --db=../mt.db --depth=1 ls known .
file

(%:~/tmp/root) monotone --db=../mt.db --depth=2 ls known . 
a/file
file

(%:~/tmp/root) monotone --db=../mt.db --depth=3 ls known . 
a/b/file
a/file
file

and after "cd a/b/"

(%:~/tmp/root/a/b) monotone --db=../../../mt.db --depth=1 ls known . 
a/b/file

(%:~/tmp/root/a/b) monotone --db=../../../mt.db --depth=2 ls known . 
a/b/c/file
a/b/file

and after "cd .."

(%:~/tmp/root/a) monotone --db=../../mt.db --depth=2 ls known b 
a/b/c/file
a/b/file

etc.

This gives me what I need. When no --depth is provided "." works as
before. Giving the whole subtree from that point.

A few questions:

1) functionality look ok?
2) --depth as param name ok?
3) patch look ok (-testcase & Changelog!)
4) I want to add this to "list" obviously, but any other subcommands
 you'd nominate for working with this option? (must be something
 that uses restriction code!)

jr
# 
# patch "app_state.cc"
#  from [392734be5cdd5ba62dd214b28aa434e67b678171]
#to [07daa7280d90fa32feb7769eed2a97fd4b10a940]
# 
# patch "commands.cc"
#  from [711e8e878e0b90261086a5a2118f9bc221c692a1]
#to [0fa1311866b0e30bee3d3b21ea3976f2d936ea7d]
# 
--- app_state.cc
+++ app_state.cc
@@ -195,12 +195,13 @@
   // careful about what goes in to the restricted path set we just
   // check for this special case here.
 
-  if (restrictions.find(dot) != restrictions.end())
+  if ((-1 == depth) && restrictions.find(dot) != restrictions.end())
 {
   return true;
 }
 
   fs::path test = mkpath(path());
+  long branch_depth = 0;
 
   while (!test.empty()) 
 {
@@ -220,9 +221,17 @@
   L(F("path '%s' not found in restricted path set; '%s' excluded\n") 
 % test.string() % path());
 }
+
+  if (depth==branch_depth) return false;
   test = test.branch_path();
+  ++branch_depth;
 }
-  
+
+  if ((-1 != depth) && (restrictions.find(dot) != restrictions.end()))
+{
+  return (branch_depth <= depth);
+}
+
   return false;
 }
 
--- commands.cc
+++ commands.cc
@@ -1705,7 +1705,7 @@
 "missing",
 "show database objects, or the current working copy manifest,\n"
 "or unknown, intentionally ignored, or missing state files",
-OPT_NONE)
+OPT_DEPTH)
 {
   if (args.size() == 0)
 throw usage(name);
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Re: monotone automate stdio

[Bruno Hertz]

Joel Crisp <[EMAIL PROTECTED]> writes:

> Hi
>
> Just a small comment; maybe a format using the numeric prefix familiar to us 
> all from RFCs like
>
> 200 OK UNKNOWN test/foo
> 201 foo.h
> 201 foo.c
>
> etc.
>
> This format is more likely to be parsable with existing libraries and is 
> familiar to people who have worked with other
> software.
>
> Joel
>
> Timothy Brownawell wrote:
>> There've been some requests for a way to run multiple automate commands
>> without needing a new monotone process for each. There's now a new
>> command, "monotone automate stdio" that takes automate commands on
>> stdin. Currently, it prefixes the output of each command with the line
>> "###BEGIN ###" and follows it with one of
>> "###END ###", "###ERR  usage###", or
>> "###ERR  msg ###" depending on whether the command was
>> successful, was invalid, or encountered some other error.
>> Tim

Depends on where you want that thing to go, i.e.

* network protocol, like http, smtp ...
* scripting facility, like sed -e 'blah1; blah2;'

Although the begin,end stuff resembles awk syntax, I'm not sure what
you're aiming at with those primitives. If you want some kind of basic
exception handling or transcation wrapping, why not try/catch
resp. transaction start and commit clauses?

Regards, Bruno.




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

Re: [Monotone-devel] monotone automate stdio

[Timothy Brownawell]

On 5/17/05, Joel Crisp <[EMAIL PROTECTED]> wrote:
> Yep, a number at the beginning of each line. It lets you detect the start of 
> the next header, distinguish different types of output
> easily, handle optional or repeated blocks of output etc. It also allows you 
> to detect badly or prematurely terminated blocks, since
> the start of the next command will cause a reset.

Hmm...

200 success
250 output
290 done (successful)

400 error/general
410 error/syntax
420 error/unknown command
450 error text
490 done (not successful)

> I think the change to the existing commands should be fairly minor, an extra 
> %s at the start of the printf which is either "201 " or
> "" for each line.

After poking around a bit, it turns out to be even easier. Pass the
command a stringstream instead of the real output, and run
"prefix_lines_with" (transforms.hh) on it before printing.

> I don't think stripping line prefixes is an insurmountable problem - after 
> all, there are many other protocols which do something
> similar.
> 
> Read the RFC for dict (http://www.faqs.org/rfcs/rfc2229.html) or the mailing 
> list expansion in SMTP
> (http://www.faqs.org/rfcs/rfc821.html) for more examples


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

[Monotone-devel] Re: .mt-ignore and .cvsignore files

[Bruno Hertz]

Nathaniel Smith <[EMAIL PROTECTED]> writes:

> On Sat, May 14, 2005 at 12:04:57AM -0700, David Brown wrote:
>> On Fri, 13 May 2005 20:39:31 -0700, Nuno Lucas <[EMAIL PROTECTED]>  
>> wrote:
>> 
>> >I understand your point. On the other hand there is no way to be fully
>> >sure they will always be the same, as "*" is a shell thing and it's up
>> >to the shell to return us the same as . would do (for example, I could
>> >have a shell that has an option somewhere to never include a
>> >*.my_extension file in the * expansion).
>> 
>> Most shells already distinguish these.  "*" in the shell doesn't include  
>> filenames that start with a '.'.
>
> Yes, but just because there's a subtle technical difference doesn't
> mean that people don't expect them to work the same, and won't
> make mistakes, experience confusion, etc. if they don't...

I think it's safe to assume your users have a basic knowledge of shell
expansion. E.g. the same applies to find . -name * vs. find . -name "*",
which people still have to somehow understand.

>
> Also, the difference here is in the other direction -- "*" would
> potentially include lots of things that _aren't_ included by ".".
> Which really is a bit surprising, no?

No. That's the feature you were talking about. Just document it.

Regards, Bruno.




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