Re: [Monotone-devel] Re: [HACKERS] SCMS question
Daniel Carosone wrote: We see this as another of a class of transformations on file content that might be performed between the workspace and the "canonical" database form. Other variations on this theme include platform-specific newlines, i18n character-set representations, and others -- up to and including code reindentation to a "project style", at least in some people's worldview. I had a specific proposal along those lines back in December: http://lists.gnu.org/archive/html/monotone-devel/2006-12/msg00079.html Even so, I was probably not the first. /larry/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Once and for all: how do you capitalize "monotone"?
The documentation is still a little inconsistent, and well, a foolish consistency is the hobgoblin of my small mind. Is "monotone" /ever/ capitalized? There are a couple of spots in the documentation where it is capitalized at the beginnings of sentences, as if it were a common noun. (We here all know that it is terribly, terribly proper, albeit with a strange capitalization deficiency.) /larry/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] _MTN/log pre-specified magic line quickie
Ben Walton wrote: The downside is reliance on an external tool, which would most likely have negative effects on the non-unix users. I'm confident that patch is available for all unix platforms, but the windows folks would need cygwin then, I believeI guess this is a large downside. It's easily solved. Monotone could just redistribute the appropriate GnuWin32 tools: http://gnuwin32.sourceforge.net/ GnuWin32 is a collection of /native/ Win32 ports of GNU tools. The tools don't need Cygwin, and they don't stick their head in the sand and pretend drive letters don't exist. Just be sure to rename the tools, say by adding "mtn-" to the front of the program names, so they don't collide with anyone else's stuff on the path. /larry/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: cherrypicking in monotone
William Uther wrote: Hrm, I can think of another kludge too (and a kludge is just what you wanted, I know); can you make *-merge label b1 and b2 the same so that we get something that looks like this: a1* /| \ / | \ a2 b1* a3 | /| | |/ | b1* b3 \ / |b4 <-- b4 has a * for unique-*-merge, not for multi-*-merge c1* Now c1* has beaten b1*, so we're fine :). N.B. labelling the two b1's the same is not too bad (he says waving hands wildly). One was machine generated from the other without conflicts. But if I understand you properly, you /don't/ want to do this. The original b1 has changes from a1->a3 and a3->b1, the johnny-come-lately b1 (what used to be labeled b2) only has the changes from a3->b1. So they're /not/ the same patch; that's the whole point of the exercise. If you wanted all the changes from a1->a3->b1, you wouldn't be using cherry-picking in the first place, you'd just merge with b1. If monotone "labeled" b2 as b1, when you later merged b4 and c1 it would think c1 had already seen the changes from a1->a3. I don't know how it would actually react; I'm still wrapping my head around these high-falutin' concepts. But surely it would behave undesirably, yes? Anyway, I don't think you /could/ "label" b2 as b1 as you suggest. The name of b2 is the SHA-1 hash of its "revision", and one of the fields in a "revision" is the "old revision", aka the parent. b1's parent is a3, b2's parent is a1. Since the text of the revision must be different, the SHA-1 must be different, so their names are different, qed. (Or am I being dense?) /larry/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] line endings as project policy
Ulf Ochsenfahrt wrote: Yes, but UTF-8 is a _multi-byte_ encoding. If you see an LF byte, you don't know whether this is a single-byte LF or part of a multi-byte sequence. Yes you do, because all multi-byte character sequences in UTF-8 have the high-bit set. If you see 0x0A in a UTF-8 stream you can be certain it /is/ an LF and /not/ part of a multi-byte sequence. http://en.wikipedia.org/wiki/Utf-8#Description Brian May wrote: "Daniel" == Daniel Lakeland <[EMAIL PROTECTED]> writes: Daniel> Consider languages like Python that have the ability to Daniel> create multiline strings, now the \r or \n characters are Daniel> part of the string. Converting them changes the behavior Daniel> and meaning of the program. This is very tricky. Any code that relies on this behaviour is very dodgy IMHO. Well I'd certainly agree it isn't platform-independent code. But where is it written that monotone should not support checking in "dodgy" code? /larry/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] A better approach for cvs->mtn? (Was: newbie: Life after cvs-import)
(Apologies in advance if this is a dumb idea.) All the recent conversation about importing from CVS to monotone makes me wonder... maybe monotone users (and developers?) would be better off devoting their energies to another approach. I gather the garden-variety ten-year-old CVS repository is a wretched hive of inconsistency; you must be cautious when dealing with older revisions, especially when migrating all this data to a new SCM. The SVN developers, their minds twisted by years of supporting CVS, have loads of experience deciphering old CVS repositories. Unsurprisingly "cvs2svn" is far and away the most successful tool at this sort of migration. So why not piggy-back on its success? Skip "cvs2mtn"; instead create "svn2mtn", or enhance tailor's support for svn->monotone conversion as needed. Then declare the first step in the official "cvs2mtn" conversion process is "convert to Subversion"! This seems like the best bang-for-the-buck approach, getting rock-solid migration for both CVS /and/ SVN to monotone--which I'm guessing are the top two SCMs these days. Cheers, /larry/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Calling the shell from a hook
Brian May wrote: Apparently Mercurial was written in Eiffel, and Monotone was written in C++ (IIRC). I prefer the compiled to native code one - Monotone. Mercurial was written in Python with C extensions for speed. It was not written in Eiffel. Of the two I gather Mercurial is generally regarded as faster; speed has been much more of a priority for them. /larry/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: patch serieses
Brian May wrote: Where can I find the website for mq? Here's the closest thing it has to an official web page: http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "mtn cat" text/binary impedence mismatch
Nathaniel Smith wrote:
On Wed, Nov 08, 2006 at 08:46:00AM -0800, Larry Hastings wrote:
So here's a patch that I think will fix the problem.
Can someone who can actually write a test for this review it? :-)
Oh! Good point. Sorry for not writing a test to begin with.
Unfortunately, I don't really know Lua, so the test driver is even less
tested than the patch. Yes, it actually has had negative
testing so far. It is my hope that some kind soul will fix whatever
errors are in the patch and repost it.
Cheers,
larry
-
#
# old_revision [a842d70f3a7546ec5c1af5d4c2eef7caddc9f511]
#
# add_dir "tests/cat_preserves_eol"
#
# add_file "tests/cat_preserves_eol/__driver__.lua"
# content [3d2c610e13755a63fe857ce7d045500a9a23a03c]
#
# patch "cmd_files.cc"
# from [12243e3b47340b2aa81cd8e26f40559fad0ab51d]
# to [70689ad71003c87e72aa02699e56744c99e5cb80]
#
# patch "platform.hh"
# from [7224b228b7c8f0476b45ed5fb929aba4d6878fd5]
# to [5959e7ef02930e75c3baa9b36b2b9869a148f837]
#
# patch "win32/make_io_binary.cc"
# from [e1ab402f330f608d17714ec0d04878b99feebc97]
# to [55fb0a7a07b64f97dfba944836537d231f2f73bb]
#
--- tests/cat_preserves_eol/__driver__.lua
3d2c610e13755a63fe857ce7d045500a9a23a03c
+++ tests/cat_preserves_eol/__driver__.lua
3d2c610e13755a63fe857ce7d045500a9a23a03c
@@ -0,0 +1,23 @@
+--
+-- test to ensure that "mtn cat file" does not write out binary files
in text mode,
+-- thereby munging the contents.
+--
+
+mtn_setup()
+
+-- take this text...
+original_contents = "look, a windows eol\r\nand a unix eol\nand an
old-skool mac eol\rand another windows one\r\n"
+
+-- ... and check it in as "eol/file.binary"
+mkdir("eol")
+check(mtn("--branch=testbranch", "setup", "eol"), 0, false, false)
+writefile("eol/file.binary", original_contents)
+check(indir("eol", mtn("add", "file.binary")), 0, false, false)
+check(indir("eol", mtn("commit", "-m", 'add file')), 0, false, false)
+
+-- now "cat" the file, capturing stdout (to . not ./eol)
+check(indir("eol", mtn("cat", "file.binary")), 0, true, false)
+
+-- the contents of "stdout" should now be the same as the contents of
"file.binary"
+check(samefile("stdout", "eol/file.binary"))
+
--- cmd_files.cc 12243e3b47340b2aa81cd8e26f40559fad0ab51d
+++ cmd_files.cc 70689ad71003c87e72aa02699e56744c99e5cb80
@@ -218,7 +218,9 @@ CMD(cat, N_("informative"),
file_data dat;
L(FL("dumping file '%s'") % ident);
app.db.get_file_version(ident, dat);
+ make_io_binary(true);
cout.write(dat.inner()().data(), dat.inner()().size());
+ make_io_binary(false);
guard.commit();
}
--- platform.hh 7224b228b7c8f0476b45ed5fb929aba4d6878fd5
+++ platform.hh 5959e7ef02930e75c3baa9b36b2b9869a148f837
@@ -34,7 +34,7 @@ int process_sleep(unsigned int seconds);
int process_sleep(unsigned int seconds);
// stop "\n"->"\r\n" from breaking automate on Windows
-void make_io_binary();
+void make_io_binary(bool make_binary = true);
#ifdef WIN32
std::string munge_argv_into_cmdline(const char* const argv[]);
--- win32/make_io_binary.cc e1ab402f330f608d17714ec0d04878b99feebc97
+++ win32/make_io_binary.cc 55fb0a7a07b64f97dfba944836537d231f2f73bb
@@ -6,9 +6,9 @@
#include "platform.hh"
-void make_io_binary()
+void make_io_binary(bool make_binary)
{
- _setmode(_fileno(stdin), _O_BINARY);
- _setmode(_fileno(stdout), _O_BINARY);
+ _setmode(_fileno(stdin), make_binary ? _O_BINARY : _O_TEXT);
+ _setmode(_fileno(stdout), make_binary ? _O_BINARY : _O_TEXT);
}
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "mtn cat" text/binary impedence mismatch
Zack Weinberg wrote:
Is there a reason not to set stdin/stdout to binary at the
beginning of execution and leave them that way forever?
Sure is. When text mode is set, stdout prepends every "\n" with a
"\r". That means printf("mtn: usage\n") gets turned into "mtn:
usage\r\n" when it hits the console. Naked "\n"s looks okay in the
console, but if you redirect it into a file then open in an editor
that's dumb about newlines (like, say, the "notepad" that comes with
Windows) it looks awful. Best to stick with the local EOL convention.
That reminds me. Does the conversion step with get_linesep_conv()
happen with "mtn cat"? I think it does not, but it should.
larry
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "mtn cat" text/binary impedence mismatch
So here's a patch that I think will fix the problem. Note that
I haven't so much as compiled it, as I don't have a monotone build
environment set up anywhere. But it sure looks okay, don't it?
Cheers,
larry
#
# old_revision [a842d70f3a7546ec5c1af5d4c2eef7caddc9f511]
#
# patch "cmd_files.cc"
# from [12243e3b47340b2aa81cd8e26f40559fad0ab51d]
# to [70689ad71003c87e72aa02699e56744c99e5cb80]
#
# patch "platform.hh"
# from [7224b228b7c8f0476b45ed5fb929aba4d6878fd5]
# to [5959e7ef02930e75c3baa9b36b2b9869a148f837]
#
# patch "win32/make_io_binary.cc"
# from [e1ab402f330f608d17714ec0d04878b99feebc97]
# to [55fb0a7a07b64f97dfba944836537d231f2f73bb]
#
--- cmd_files.cc 12243e3b47340b2aa81cd8e26f40559fad0ab51d
+++ cmd_files.cc 70689ad71003c87e72aa02699e56744c99e5cb80
@@ -218,7 +218,9 @@ CMD(cat, N_("informative"),
file_data dat;
L(FL("dumping file '%s'") % ident);
app.db.get_file_version(ident, dat);
+ make_io_binary(true);
cout.write(dat.inner()().data(), dat.inner()().size());
+ make_io_binary(false);
guard.commit();
}
--- platform.hh 7224b228b7c8f0476b45ed5fb929aba4d6878fd5
+++ platform.hh 5959e7ef02930e75c3baa9b36b2b9869a148f837
@@ -34,7 +34,7 @@ int process_sleep(unsigned int seconds);
int process_sleep(unsigned int seconds);
// stop "\n"->"\r\n" from breaking automate on Windows
-void make_io_binary();
+void make_io_binary(bool make_binary = true);
#ifdef WIN32
std::string munge_argv_into_cmdline(const char* const argv[]);
--- win32/make_io_binary.cc e1ab402f330f608d17714ec0d04878b99feebc97
+++ win32/make_io_binary.cc 55fb0a7a07b64f97dfba944836537d231f2f73bb
@@ -6,9 +6,9 @@
#include "platform.hh"
-void make_io_binary()
+void make_io_binary(bool make_binary)
{
- _setmode(_fileno(stdin), _O_BINARY);
- _setmode(_fileno(stdout), _O_BINARY);
+ _setmode(_fileno(stdin), make_binary ? _O_BINARY : _O_TEXT);
+ _setmode(_fileno(stdout), make_binary ? _O_BINARY : _O_TEXT);
}
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "mtn cat" text/binary impedence mismatch
Timothy Brownawell wrote: There's a make_io_binary() or somesuch in platform.hh that does that, I think it's only used for automate right now. Beautiful! That suffuses me with confidence. I shall contribute a patch straightaway. larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "mtn cat" text/binary impedence mismatch
Brian May wrote: Larry> If I check in a text file on Windows, then use "mtn cat" to Larry> stream it to the console, all the \r\n line endings get Larry> converted into \r\r\n. Maybe it could not do that? Maybe I am mistaken, but I didn't think monotone supported converting text mode formats yet? As in all files are treated as binary on all platforms. In any case, converting \r\n --> \r\r\n seems broken, shouldn't it be converting to just \n? Sorry, I should have been more explicit. The problem is that it doesn't convert the file, but stdout does. When mtn.exe writes out a file, it does so in binary mode. However, stdout is always implicitly opened in text mode, which on Windows means "any time you see \n, write out \r\n". Up go the lights, out go the flags, on come the dancers, bang! goes the drum, and now when the file contains "\r\n" stdout flushes the "\r", sees the "\n", and writes out "\r\n", thus giving you (or me really) "\r\r\n" every time... and the show has begun. I'll try to contribute a fix (using _setmode() on _fileno(stdout)), but lacking any sort of build environment it'll be rather like building a ship in a bottle. Still, poking around at MinGW header files gives me some hope that this will work. Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] "mtn cat" text/binary impedence mismatch
If I check in a text file on Windows, then use "mtn cat" to stream it to the console, all the \r\n line endings get converted into \r\r\n. Maybe it could not do that? Preferably with _setmode() wizardry, so it worked for binary files too, though stripping the \rs from the stream would get it to limp along for text files. Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] m7 rises from the dead... reborn with new non-irritating behavior!
Howdy folks! Today I announce a new version of m7. In case you forgot, m7 is a proof-of-concept Python script that adds simple "local revision numbers" to monotone. These local revision numbers are simple monotonically increasing numbers affixed to revisions, and you can use them anywhere you specify a revision on the command-line. To ensure it's unambiguous, you need to prefix the revision number with a colon. So, if revision "818b9c9604efad446e5729d82a707714fea92cde" was local revision number 5, these commands are equivalent: mtn cat --revision=818b9c9604efad446e5729d82a707714fea92cde foo.cpp m7 cat --revision=:5 foo.cpp When I announced m7 over a year ago I didn't know what to expect. Reactions were mixed, from negative like "I would never use this, and I hope no one else does either", to positive like "I would never use this, but it's kind of neat"*. The original objection to m7 was its use of tags to track local revision numbers. Later I changed to custom certs, but that was little improvement. Since these tags & certs become part of your database, they would be sync'd to external users, even though they were primarily intended for local use. Correspondents on the monotone mailing list felt these certs would clutter up their databases and network traffic. However! Some senior monotone fella, surely either Graydon or Nathaniel, suggested an approach that doesn't need these certs―and is both faster and less error-prone to boot. It relies on a slightly-obscure feature of SQLite: every table has an indexed unique auto-incrementing integer column, whether or not it specifies one explicitly in its schema (see http://www.sqlite.org/autoinc.html ). So each entry in the revision table already has a locally-unique "revision number", ready-made and just waiting to be exposed to the monotone user. This even works, automatically, for external revisions you get from a network sync―a feature the old m7 never had, and never would! The only downside to this approach is a descent into "mtn db execute" territory, but it's a quick trip. I am therefore pleased to announce m7 version 0.8, which does not create extra tags or certs. Its only overhead is three "database variables" for local configuration which do not get propogated via netsync. You should feel free to download it and play around with it, secure in the knowledge that it will not "infect" your repositories with extraneous certs. m7 is written in Python, and requires version 2.3 or higher. Apart from the exposed local revision numbers, m7's other main feature is a more readable form of annotate. I tinkered with this a little too; now by default it prints a legend of the relevant revisions at the top before the annotated source. In case you're an existing m7 user, you can remove all the old m7 cruft by running "m7 unpopulate" from your work directory. (And you could give me the shock of my life by letting me know you were actually using m7.) You can read more about m7, and download a copy, here: http://www.midwinter.com/~lch/programming/m7/ Cheers, larry * This is exaggerated for comedic effect, though I do believe I have zero active users of m7. But let it be said that the monotone developers were always supportive of my experimenting with monotone's UI. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: How do I merge 2 unrelated branches into 1 ?
Bruce Stephens wrote:
"Dmitry Kakurin" <[EMAIL PROTECTED]> writes:
I also wonder why keeping track of dirs is necessary. Perforce (for
example) gets away with only keeping track of files and creates dirs
on demand.
Monotone did that (pre 0.26). It turned out that tracking directories
as well would make some things better.
It's definitely better. Since Perforce can't tell the difference
between a file and a directory, sooner or later you always seem to wind
up with a file checked in that shares the name of a directory. Back in
the day when I used Perforce (2002.1 iirc), if you said
p4 add foo
and foo was a subdirectory, Perforce would just *assume* it was a
file. An unpleasant shock for the first-time user coming from another
SCM that does explicitly support directories.
But even the seasoned Perforce user might stumble across this; if they
ran
p4 add *
it would happily add *all* the subdirectories.
Once a directory is checked in, it becomes a race to see who gets
created first, the "foo" file or the "foo" directory. Whichever one
wins the race means the other one loses ("can't write file"), at which
point the checkout fails. Now you have to fix it in the repository
before you can checkout, as you mutter quietly to yourself about SCMs
that don't understand freaking *subdirectories*, they've only been
around for more than thirty years, grumble grumble grumble.
I believe they had a hack that said "if the last character of a file
specified to p4 add is a /, ignore it", relying on the globbing of some
shells that add the slash there. Globbing under Windows doesn't add
that, so that didn't help me. I dimly wonder if they have a better fix
in place now, but I stopped following Perforce years ago.
larry
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Specifying multiple --message arguments for commits
Richard Levitte - VMS Whacker wrote: On some platforms, then end of line is "\r\n". On some others, it's not even a character, it's writing down the line as a record with a length indicator. But I'm sure the stream is flushed either way. I think those differences are abstracted away by the "text file" handling in C. For instance, MSVC on Windows defines std::endl as '\n' followed by a flush, even though the local EOL convention is "\r\n". Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Poll] Domain for monotone
monoto.ne ? ( .ne == Niger ) larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: RFC: mtn split (Was: [Monotone-devel] Best practice using monotone)
Chad Walstrom wrote:
I don't think this would be possible. By the time you are inside the
editor to record your comment, monotone has already selected the files
to commit in the new revision. The best you could do is abort the
commit by comparing the log template before and after. If there were
any "MTN:" prefixes missing, abort. If there was no comment, abort.
Surely it's possible. How about:
Compare the MTN: prefixes in the comment against what mtn
originally generated.
If they don't match:
Generate an "ignore list" of the files that were removed from
the MTN: prefix lines.
Throw away the current calculated whatever ("changeset"?
"revision"?).
Generate a new whatever, but this time ignore all files on the
"ignore list".
Submit the whatever.
And don't call me Shirley,
larry
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] mtn feature request: mtn commit --diff
When I check in, I like to go over the full diff. It's a last chance
to double-check what goes in, as well as reminding me of exactly
everything that changed, in case I forgot to do something or there are
extra changes that I forgot about.
Right now I do it with a shell script:
mtn diff > x
vs x
mtn commit
("vs" == "Visual SlickEdit"). It'd be nice if commit took a
--diff flag, indicating that I wanted to see all the diffs rather than
just a list of changed files. In order to be cricket, it would of
course have to prepend every line of the diff with #, so it didn't get
interpreted as a comment.
For completeness' sakes, it might be nice to support --unified,
--context, --external, and --diff-args for commit --diff. Though
personally I wouldn't use them.
Cheers,
larry
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] pluck problem
In FORTH, if you want to copy something that is n levels down on the argument stack, you use PICK. "5 4 3 2 1 4 PICK . CR" would print 4. And, really, what has monotone drawn its inspiration from, if not FORTH? :) Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Subversion Update Command Considered Harmful
Bruce Stephens wrote: I'm not quite sure what it's saying, except that review is important, and that CVS and subversion don't make it so easy. I'm not sure why he argues that that makes git better. What I got from it is "CVS and SVN don't give you control over what changes you get when you 'update'." Most folks remedy this by working in their own branch, but he points out (correctly) that CVS and SVN maintain no internal state for branching, make working in one's own branch a continual nosebleed. He suggests git is superior because "update" is such a manual process, allowing you to cherry-pick all your updates. I contend that working in your own branch is still better, assuming you use a reasonable rcs that manages branch state for you. (Cherry-picking would occasionally be handy too, but I don't think it's crucial.) git's cherry-pick-all-updates approach sounds tailor-made for Linux kernel development, but a bit labor-intensive for conventional development. larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bikeshed] envelope please
Nathaniel Smith wrote: For the bookkeeping dir, _MTN seemed to have the most consensus (though IIRC Graydon liked _mtn better, so if he wants to put in a last minute plea, I guess we can talk). I'd prefer lowercase as well. I mean, the proper name of the project is "monotone", not "Monotone", in pointed violation of custom of uppercasing proper names. graydon seems to avoid uppercase as a matter of strictest policy (note how it applies to his name as well). Of course, I'm on Windows, so I could convert it to lowercase anyway and get away with it. -- maybe change the configuration dir from ~/.monotone to ~/.mtn. I'm for it; a foolish consistency is the hobgoblin of my small mind. You seem to have the eggs out, and have made your way through most of the dozen in your quest for an omelet; I say you might as well break all of 'em while you're at it. Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bikeshed] once more on bookkeeping dirs...
Nathaniel Smith wrote: So, since 0.26 isn't coming out for at least a week anyway (stupid end-of-term), 0.26 is coming out that soon? I figured it was months away. Rock on! I'd sort of like to hear more opinions on this, to get a sense of the community feeling... As a Windows guy, it doesn't make any difference to me. If I get tired of looking at the directory I can always set the "hidden" bit. I suppose I would find a lengthy name like .MTN-bookkeeping-directory-nobudy-cumz-in-here-sekrit tiresome. I take it the leading underscore is to help with sorting order? I find that a bit strange, as it would sort to the middle, between the upper- and lower-case characters. Though I guess it's preferable to sorting to the middle of the upper-case letters, as M does. Still, ever the iconoclast, how about a plus-sign, as in +MTN? That would sort it to the head of the directory every time, and it's not a special character to any shell I know of. (And, yes, I genuinely expect that suggestion to go exactly nowhere.) I've stood near a VMS system on several occasions, and even looked at the chassis of one once while a coworker pointed at it. I am ambivalent on whether monotone should limit its options in order to accomodate VMS's antiquated filesystem semantics. After all, and please correct me if I'm wrong, I understand that VMS has been on its way out for years. (Truthfully, I'm surprised that folks are using bleeding-edge software like monotone on something as, well, non-bleeding-edge as VMS.) One possible solution would be a mtn command that prints the basename of the bookkeeping directory on the local computer, so that scripts can ask for it by name. Thus a well-written script could run unmodified on VMS. A poorly-written script could get diffs from people who care ;) Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] renaming monotone executable (again)
What to switch to: I nominate "mon", "mo", and "m7". "m7" is what I actually use. (The '7' represents the seven missing letters, like I18N and L10N.) The downside: M and 7 are both typed by the same finger on a QWERTY keyboard. Whatever you pick, I won't complain... well, unless you pick "ls". Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: the line-ending discussion
Graydon Hoare wrote: This is not what monotone does now, but I find it an agreeable road forwards. Does anyone disagree? As long as the text/binary setting can be overridden on a file-by-file basis, and can be changed at whim, I think that's sufficient. Everything else is gravy. What form do you envision the "project policy" taking? Lua functions that return whether a file should be binary or text, and what eol convention to use? Finally, I think data should be explicit, rather than implicit. Therefore I suggest that the "text / binary" attribute be an explicit per-file setting, rather than "if it's there it's one way, if it's not there it's the other way" as you suggest in your previous email. Best wishes, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Bug in CRLF conversions
FWIW, the Perforce documentation says they handle EOL translations like
this:
When you add a file, you can explicitly specify what "type" it
is. Valid types in the current version are "binary", "text",
"symlink", "unicode", and two types for those funny Macintosh resource
files ("apple" and "resource"). The "type" is part of the per-file
metadata stored in Perforce.
The "text" file type translates line endings; they don't say
how. "unicode" means "store the file in UTF-8 in the repository, and
translate to the local code page upon sync/checkout". (I bet "unicode"
does EOL conversion too, but they don't say.)
If you don't explicitly specify a type, Perforce looks in the
"typemap". This is a per-depot text file, mapping wildcard filename
specifications to types. It is empty by default.
Failing to match the file in the "typemap", it guesses at the
type by examining the first 8192 bytes. If it discovers "nontext"
bytes, it uses "binary", otherwise it uses "text". A "nontext" byte is
any byte > 127 (in other words, has its high bit set).
You can change a file's type at any time.
There are also type modifiers, like "+k" (perform keyword
expansion, like $Date:$), "+x" (set execute bit), and more.
All this information was gleaned from publically available
documentation from Perforce's website. The main page of interest is
the documentation on "file types", here:
http://www.perforce.com/perforce/doc.052/manuals/cmdref/o.ftypes.html
My notes on this:
I'm surprised at their "nontext" heuristic; before I saw the
documentation, I was guessing they'd look for characters < 32 that
weren't valid whitespace characters. A random sampling of binary files
on my hard disk shows plenty of zeros in the first 256 bytes.
Their documentation mentions that some PDFs fail the file type
guesser. PDFs store comments first, and some wordy PDFs have > 8k
of ASCII comments. Though they ship an empty typemap, they do have a
list of "recommended" entries which includes "any file ending with pdf
-> binary".
I assert that no solution will do the right thing by default for
everyone at any time. But a conservative default, combined with the
ability to adjust the transformation on a file-by-file basis at any
time, should be Good Enough.
Cheers,
larry
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Bug in CRLF conversions
Bruce Stephens wrote: (I'm also not convinced by your python example: python is well known for using layout as syntax, so there's no contradiction in saying that a line break is "just a layout indicator", and that it indicates the end of a statement.) Just so. I just tested with Python under Windows and Linux, and it doesn't care what kind of EOL characters it gets. I terminated lines with each of the four possible endings (CR, LF, CRLF, LFCR) and Python understood each of them to mean EOL. Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Bug in CRLF conversions
Speaking as a Windows developer, let me pitch in with a couple thoughts: Casual Windows users may not have software that copes with varying line endings, but all the programmer's editors deal with it no problem. Still, it'd be nice if monotone helped to mitigate the problem. Personally I'd prefer it if monotone stored text files in some canonical format, and converted to/from local format on sync / commit. Normalizing eols to just LFs seems fine to me, as would stripping out the payload from $Foo:$ tags (not that monotone handles those yet, I gather). Two people checking in the "same" file, where they differ only by the local eol convention, should result in generating the same hash. How should it normalize text files with inconsistent eols? If I'm on Windows, and I check in a file with CR LF LF, what should it do? I suggest monotone use the following heuristic, regardless of the local platform: when you first see either CR or LF, store an LF. If the next character is the other eol character, ignore it. Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: comments on .sqlite3.binary branch
Matt Johnston wrote: New versions of zlib (1.2 and up) can decode gzip data too, though I don't think we want to force people to get newer versions. For the record, zlib 1.2.0 shipped on March 9th, 2003, making it nearly three years old. Anyone bleeding-edge enough to be running monotone probably already has zlib >= 1.2. http://www.zlib.net/ChangeLog.txt Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] rfc on h: selector behavior
Nathaniel Smith wrote: I guess the comparative rarity of decent scripting on win32 might be an argument for more power before having to switch over; dunno. Whatchoo talkin' about, Willis? There are freely-available Windows ports for all the popular scripting languages (and even a few decent ones). Anyone interested in building complex selectors--or using other people's scripts to do so--can download any language they need. Sure, they don't come pre-installed with the OS, but then neither does monotone. So I don't think that's a serious impediment. larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Serving * does not work
Florian Weimer wrote: Alvaro Herrera wrote: monotone server % Wouldn't this cause problems on Windows? Only when used in a .BAT file (the lame Windows equivalent of a shell script). You'd have to quote it by using two of 'em. larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Serving * does not work
Straw poll? % vs. *? Leave it as *, and as dscherger suggested in #monotone, change it so * is the "default branch" served if unspecified. larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: usher and roaster? [was Re: [Monotone-devel] Merging cvssync in small pieces: Pipe abstraction]
Jon Bright wrote: Zbynek Winkler wrote: I also remember reading about some "roasters"...? "rosters"... though I've also no clue what they are. I've been hanging out in the #monotone IRC channel, and believe I have a basic theoretical understanding of "rosters", which I will now trot out. If there are any factual errors in the following, I hope someone will correct me. The following definition was run by Graydon, who gave it his stamp of approval: A "roster" is a local-only data structure that contains cached information about a particular revision/manifest, optimized to make many operations more correct and much faster. It's not a change the underlying model/paradigm, but it is a restructuring of how monotone works with that data internally. "manifests" and "revisions" are much the same as before, and are still how revision information is exchanged between databases; "rosters" are never sent over the wire, they are always built and maintained locally. The rosters branch touches nearly every internal data structure, so one will have to perform an explicit data migration when upgrading to monotone with rosters. (I believe the first attempt at such a migration happened earlier late Monday night!) I can name a couple of data structural changes right off the bat: The ".mt-attrs" hack to store file attributes is gone, they now have a way of storing attributes internally to monotone. A directory is now represented explicitly, whereas currently in monotone (as with Perforce) it is an implicit part of the path to a file. The format of "manifest" is now basic_io. Files and directories are now assigned a "local identifier", which identifies neither the name nor the contents of the file, but rather its "essence". It is this identifier that lets you rename and change a file in a single revision, yet track it back to its previous revisions. (The "local identifier" is an local-only optimization, as the external representation is rich enough to allow you to track such changes.) The one-sentence "elevator pitch" for rosters: Any time you ask about some problem in #monotone, either graydon or njs says "oh, yeah--that's fixed with rosters". larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: A Two-Fold Proposal: On Formats And Front-Ends
Graydon Hoare wrote: We have to use *some* level of custom-notation because almost no other text notations normalize whitespace. Hashing imposes unique requirements. I agree with your second statement, but not your first, unless you consider "normalizing the whitespace of an existing format" to be "some level of custom-notation". Using XML/ASN.1/JSON and mandating an exact approach to formatting whitespace would have met monotone's requirements for reproducability and hashing. Really, though, as long as your formatter produces consistent output, and that format is replicable by other people when important, that would work just as well. It's valid, if inconvenient, to define the standard for "normalized" whitespace as "what the formatter in monotone does". Graydon Hoare wrote: basic_io was designed to be *relatively tolerable* for humans to read as well as machines. Wheras Nathaniel J. Smith wrote: The point of the automate split is, of course, so we can make the question "what format is best for humans?" and the question "what format is best for computers?" into different questions... I'm with Nathaniel here, as I view those are conflicting goals. As per my original proposal, I'd make the internal format convenient for programs to digest, and the front-end would convert between that format and something far more pleasing for humans to gaze upon. Trying to serve both audiences with a single format had simply never occured to me, so I didn't recognize basic_io as being a dual-purposed solution when I saw it. But that's all neither here nor there. I have my answers. There is a standardized data interchange format, basic_io, which will be used for all new business in internal data formats. Public opinion is ambivalent regarding a split between the front-end and back-end; that part of my proposal was generally ignored in favor of the data format kerfuffle. If I or someone else engineered such a split, I don't get warm fuzzy feelings that it would be accepted into official monotone releases. Far more likely to make it in would be a re-engineered "stdio" mapping the breadth of monotone's command-line to basic_io stanzas (both in and out). Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: A Two-Fold Proposal: On Formats And Front-Ends
Bruce Stephens wrote: (Pipes can be made to work properly even on Windows nowadays, can't they?) Gosh, only for the last dozen years, give or take. ;-) m7 uses pipes, and I wrote it on Windows. larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] A Two-Fold Proposal: On Formats And Front-Ends
Alex Queiroz wrote: If the first step in writing your own monotone front-end was "call the Lua parser", it would make writing front-ends a major headache. Particularly for people not writing their front-end in C. Why is that different from having to call the JSON parser? Because there are implementations of JSON for all popular (and many unpopular) languages. Already we have front-ends for monotone written in many exotic languages*: OCaml, Ruby, Java, Perl, and Python. All these languages have reference implementations of JSON, wheras none of them have implementations of Lua. Worst-case, if there were no reference implementation of JSON for your chosen language, and you were forced to write the parser yourself, writing a JSON parser is far more approachable than writing a Lua parser. Also, Lua is an entire scripting language, and as such has a much more complicated API than JSON. So the setup code to parse some Lua input would be far more complicated than the equivalent code to setup parsing JSON. Of course, this could be hidden in a library, but again such a library would almost certainly be written in C (or C++) and hard to use from other languages. larry * In fact, it looks like none of the tools listed on montone's "GUIs/other tools" page was written in C! I guess anyone who'd use monotone these days is already far enough off the beaten path that they don't mind living on the leading edge of linguistic civilization. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] A Two-Fold Proposal: On Formats And Front-Ends
Well, the proposal has been up for six hours, and no threats of bodily harm yet. So that's something--guess y'all are friendly after all. My thoughts on the replies so far follow. Joel ([EMAIL PROTECTED]) wrote: I notice that JSON doesn't support circular references in serialized object trees. Is this going to be a problem? I'm not really qualified to answer, but... I doubt it. The current dazzling myriad of text formats doesn't support any explicit circular references either, and yet monotone works fine. Whatever circular references already exist are implicit in the data being stored. Julio M. Merino Vidal ([EMAIL PROTECTED]) wrote: What about YAML (http://www.yaml.org/)? It could be useful too. That's a new one on me. Looks okay at first glance. It's way more complicated than JSON, but then that's because it supports a much richer set of types (sets, binary values stored in base64, a reference scheme). Also, they don't seem to provide a reference implementation for C, just for several scripting languages. There does appear to be a C implementation here: http://tpe.freepan.org/repos/oren/yaml-parser/ but it hasn't been updated for over a year. I think I prefer JSON. I don't think monotone would benefit greatly from the larger set of types; JSON has a "right-sized" feel to me. But if monotone switched to YAML, I wouldn't complain, I'd roll up my sleeves and get to work. Hendrik Boom ([EMAIL PROTECTED]) wrote: Would (multiple) front-end(s) and a shared engine library do? Perhaps, perhaps. My goal is to write a front-end in Python. For that, an executable where I talk over pipes is preferable to a shared library. But if one of the front-ends provided exactly that interface, I wouldn't mind. One of the reasons I proposed splitting it into two executables was to erect a "chinese wall" inside monotone, to keep it honest. If every operation ever run from the command-line went through this pipe interface, then there would be no possible way to circumvent it. If the interface is a shared library, someone could say "Doing operation x with these ding-dang pipes is a pain in the keister, so I'm going to make an end-run around the pipes and make up a special API call that makes this way easier for me." If the only interface is the pipe, they wouldn't have that option, and they'd have to "suck it up". [XML] fails to distinguish a type from a field-selector. [...] ASN.1 makes the same fatal mistake. [...] JSon also fails to distinguish between types and field-selectors. I'm afraid I don't understand the distinction you're drawing. Can you elaborate? And is this something that you know monotone would need? Right now I doubt monotone's various output formats make this distinction either. Alex Queiroz ([EMAIL PROTECTED]) wrote: What a lot of people forget is that Monotone has already a parser for a very powerful data description language: Lua. Although Lua is a modern language with co-routines, tail calls, anonymous functions, lexical scoping etc. it was first designed as a data description language. If the Lua syntax was used thoroughly in Monotone, that'd be zero effort in writing or reusing another parser. Zero effort for monotone, but great heaping handfuls of effort for anyone else. If the first step in writing your own monotone front-end was "call the Lua parser", it would make writing front-ends a major headache. Particularly for people not writing their front-end in C. (There are, understandably I think, no Lua bindings for Python, Perl, OCaml, and the like.) Also that that wouldn't help with the output data. monotone would still need to write an output formatter. Though I acknowledge that this piece would be pretty easy. Marcel van der Boom ([EMAIL PROTECTED]) wrote: implement a --format switch which takes something like a printf() format string/file, where you can deviate from the standard output format. I agree, that would make writing front-ends using the existing monotone executable simpler. But it wouldn't solve the "tower of babel" problem with respect to file formats. Also, it wouldn't allow any real flexibility. For instance, what would you do with monotone automate graph, where you list multiple ids per line? How would you format monotone automate inventory? Or monotone status? How would this handle error conditions? The approach you propose would solve 80% of the problem. I'd rather solve 100% of the problem, even if the solution is more complex. As Mr. Einstein once said, "everything should be made as simple as possible, but no simpler." Having to have a separate daemon to set up would not be very welcomed by me. Right now this is all blue-sky initial planning, so I get to play Santa Claus and say things like "well, of course you wouldn't be forced to use monotone in daemon-mode." Anyway, I doubt we'd want to change to that being required; as you say, having monotone being this standalone non-daemon thing is very pleasant. Bruce Stephens ([E
[Monotone-devel] A Two-Fold Proposal: On Formats And Front-Ends
I have for you two separate but intimately related proposals, and I'm going to describe them in reverse order of implementation because it flows better. Keep in mind, I'm still quite wet-behind-the-ears with respect to Monotone; I typed my first monotone command less than two weeks ago. It wouldn't surprise me if this was all a bad idea for any number of unforseen reasons. And yet I bravely post, having read somewhere that the monotone community is "friendly". So... be kind. :) Right now monotone makes life tough for front-end developers. The main problem I see is the N different output/file formats of monotone, where N is distressingly large: There's the tag filename (where filename may have whitespace) of manifests. There's the name: [value] or sometimes name: "value" blank-lines-are-apparently-significant of revisions. There's the name: value of certs. There's the name "value" blank-lines-are-significant format of .mt-attrs and others--the "stanza" format. (Are revisions "stanzas"? I can't quite tell.) I count three output formats unique to monotone automate: whitespace-separated tags (newlines are significant), the wild world of automate inventory, and the l:e syntax of automate stdio. There's the "packet" format. There's the catch-as-catch-can output of running various monotone commands; log, status, list keys, and list certs have wildly different output formats, just to name a few. monotone's data stream--its input, its internal storage, and its output--is a tower of babel, and I had my work cut out for me when I set out to write m7. (Thank goodness for Python's excellent regular expressions module.) For a project named monotone, its output is certainly polyphonic! Additionally: while the monotone automate brace of commands is a reasonably good idea, and a step in the right direction, it is woefully incomplete. When writing m7, I had to call lots of non-automated monotone commands directly because monotone automate doesn't offer any actions. You can't add/delete/rename, you can't commit, you can't create certs, you can't push/pull/sync. All but one of the automate commands are queries; the only exception is stdio. I suspect this is because monotone doesn't "eat its own dog food": monotone doesn't implement its user-visible commands using the automate interface, it just does operations directly on the database. Seemingly all the automate commands were added ad-hoc, to support the needs of history visualization tools I'm guessing. But, since people weren't writing general-purpose front-ends that day, monotone automate offers no assistance to people adding files or committing changesets. Sure, we could add a spate of new monotone automate commands, in an effort to catch it up with the interactive command-line interface. But even if it caught up, it would likely fall back behind later, again because monotone doesn't "eat [its] own dog food". One unfortunate side effect of this: it denies a front-end any real atomicity. There are many operations where m7 has to run mulitple monotone commands, and since each one is a separate monotone instance, there's no way to ensure atomicity between them. As a result, most m7 commands suffer from race conditions. This is particularly bad for commands that change the database; if you ran two m7 commits at once, I rather suspect you'd get two revisions with the same local revision number cert. To me the solution is clear, and it is here we arrive at my first actual proposal: separate presentation from application logic by breaking the current monotone executable into two pieces. One piece would be the "engine" that did all the actual work. The second piece would be the "front-end", or "driver", which drives the monotone engine (as gcc drives the front-end, back-end, and linker). The driver would provide the command-line interface of the current monotone executable, convert internal messages to their user-friendly localized equivalents, etc. The communication between the two would be done over pipes in some easy-to-cope-with data specification. This has many advantages: New front-ends, rather than depending on the vaguaries of monotone's frantic command-line arguments and all-over-the-map output, would have a single, stable, easily-digested input-output format to deal with. Thus making it much easier to write and maintain front-ends, and making their communication channel with monotone far more future-proof. This new breakup of responsibilities would put all front-ends on equal footing. This would force all monotone operations to be available via this new "automation" interface, thus promoting all front-ends to first-class citizens, and--if the interface is generalized enough--allowing them to offer new functionality not afforded by the monotone command-line, just as m7 does, but hopefully preserving atomicity. If you ship file data over the pipes, and restrict the engine to so the only
Re: [Monotone-devel] Announcing "m7", a monotone front-end... which adds revision numbers!
The people have spoken: m7 should use custom certs, not tags. Announcing m7 version 0.2! You can download it at the m7 homepage: http://www.midwinter.com/~lch/programming/m7/ And I'm hoping that someone actually will download it, someday. Maybe even someday soon. This change worked out pretty clean. The custom cert is named m7-db-$username-$computername, whose value is just the revision number. This means you could theoretically populate other people's checkins with local revision numbers and not worry too overly much about collisions. (Though I think that wouldn't be cricket.) However, it's not all skittles and beer. Producing the list of tags with their local revision numbers is a lot slower this way, so now there's a noticable slowdown before the output of tannotate. The price of progress, I guess. Justin Patrin said: Oh, and as for O(1) vs. O(n) I think that's a very false assumption. True, you're going to start more processes, but monotone itself has to do internal things [...] Sure, but it's the per-monotone-process overhead that I was really speaking to. I imagine that monotone gets going, it's mighty quick at culling certs from the database. If I could do it all in one invocation of monotone, it would be a hell of a lot quicker than the N invocations I sometimes must use now. larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Announcing "m7", a monotone front-end... which adds revision numbers!
Richard Levitte - VMS Whacker wrote: for x in `monotone automate select c:tag='monotree*'`; do monotone list certs $x; done Ah, so they could be pulled out of monotone without resorting to SQL today. Thanks! (It would be an O(N) operation, as compared to an O(1) operation with monotone list tags, but it should still be fast enough that the user wouldn't notice.) 1. it makes special cases of tags. So far, a tag is a tag is a tag. What you propose is that a tag is a tag... unless it looks this way. I don't see how these tags are "special cases". My intent was that they be normal tags, just like any other tag. The only thing arguably "special" about them are that m7 provides a special command-line shortcut to refer to them, m7 tannotate can recognize and abbreviate them, and there are a lot of them. But they work just like normal tags, because they are normal tags. I can say monotone cat revision lch:flu:7 if I like, works fine. Indeed, m7 currently relies on that fact; the : shortcut simply gets expandsed into t:$username-$computername- before it runs monotone. 2. it assumes that everyone will use m7, and completely ignores the possibility of a mixe environment, As with your previous point, I fail to see how this approach "ignore[s] the possibility of a mixed environment". There is nothing in m7's design or implementation that would preclude interoperating with non-m7 users; m7 does nothing that breaks monotone's data model. You continue to use monotone directly, and I could sugarcoat it with m7, and we could push and pull between our databases without incident. If you're really just restating your earlier point about "well, but there'd be a lot more tags now, and that would be inconvenient", then my reply is again "that's a user interface issue". Let me be clear: I am hardly opposed to changing these tags to custom certs. Indeed, that could offer its own advantages. But I am curious about the reaction of the general monotone community. I am now well acquainted with Mr. Levitte's opinion; what do the rest of you think? Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Announcing "m7", a monotone front-end... which adds revision numbers!
Richard Levitte - VMS Whacker wrote: I wish you would have used a different cert than the tag one, and I certainly hope noone will choose to populate the monotone database. "monotone list tags" will just not be the same experience (I can already see myself screaming "GAH!")... Well, I agree about not populating net.venge.monotone, simply because m7 is still in its early stages. Though I do hope people will play with it in earnest, and I am eating my own dog food. As far as not using tag certs for the ids, I don't really agree. Ignoring the specific argument cited above, are there any other reasons they shouldn't they be tags? After all, this revision number tag that m7 writes out is "a symbolic name given to a revision", and that's the very definition of a tag cert, straight out of the monotone documentation. I see it as entirely appropriate. There's also a near-term logistical problem. Right now, if I used an arbitrary other cert, I wouldn't be able to easily get a list of them out of monotone. Tags I can list with monotone list tags. But arbitrary certs are unretrievable unless either you know something about them (like what revision id they are joined to) or you're willing to delve into SQL. Though I'm sure if I whined enough / contributed code, we could have a nice high-level interface for querying for these in the next release. As for not wanting to see untold kajillions of tags, I see that as a user-interface issue. The solution is better tools at dealing with arbitrarily large collections of tags, not telling people "oh, don't use a tag there! you'll clutter up monotone list tags!" For instance, m7 list tags could weed out all tags that conform loosely to its default tag specification. Or only show you tags from the last month, or six months. Or both. Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Announcing "m7", a monotone front-end... which adds revision numbers!
(Well, okay, not gen-u-ine revision numbers, but an incredible simulation.) m7 is a Python script that works as a drop-in replacement for running monotone directly. It's known to run on Windows, Linux, and Mac OS X. It requires Python 2.3.5 and monotone 0.22. It is open-source, released under a Zlib-style license. The current version is 0.1, the first public release. Why might you want to use m7? m7 automatically tags each new revision with a reasonably-unique tag, including a monotonically increasing number. Also, anywhere you can specify a revision id, m7 accepts a shortcut syntax (: followed by the revision number) to specify one of these tags. For instance, to refer to your thirty-fifth local revision, you would just say :35. Finally, m7 has a variant of annotate that substitutes these new abbreviations for the 40-character hex tags (wherever possible), making it a lot easier to read. You can read more about it, and download a copy, here: http://www.midwinter.com/~lch/programming/m7/ Cheers, larry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
