Re: [Monotone-devel] monotone update overwrites local changes
See tests/t_add_stomp_file.at ;) -emile On Tue, 2005-05-10 at 10:52, Robert Bihlmeyer wrote: Suppose I have two working copies A and B, and an unknown file F in both. I then add A/F, commit this, and finally update B. monotone will trample over the contents of B/F overwriting it with the version committed from A/F. I don't think that's sensible behaviour, as update should not be a destructive operation. One option is to punt like CVS does and refuse to update unless B/F is moved away. More useful would be to initiate a two-way-merge between the repository version and what's already there. The latter is already done when I do monotone add B/F before updating. (A middle-of-the- road solution would be to punt with a reminder that one can either move F away or add it to get merging behaviour.) +-- The Two Phases Of University Employment: 1. Doesn't know enough to get a Real Job. 2. Knows too much to want a Real Job. -- sharks +-- signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] error while dropping a directory
1) I created a new monotone database. 2) I created a new project in the database 3) I added a bunch of existing files and directories in the project 4) I removed one of the subdirectories (i.e., build/gsl-1.4) have fun debugging ! Mathieu [EMAIL PROTECTED] build]$ monotone drop gsl-1.4 monotone monotone: adding build/gsl-1.4 to working copy delete set monotone: warning: SORRY -- 'drop somedir' is not going to work. monotone: warning: Revert and try 'find somedir -type f | xargs monotone drop' monotone: fatal: std::logic_error: path_component.cc:53: invariant 'I(!null_name(*i))' violated monotone: monotone: this is almost certainly a bug in monotone. monotone: please send this error message, the output of 'monotone --full-version', monotone: and a description of what you were doing to [EMAIL PROTECTED] monotone: wrote debugging log to MT/debug [EMAIL PROTECTED] build]$ monotone monotone --full-version monotone 0.19 (base revision: 168adf9537ff136c9b7fe7faad5991f92859390d) Running on: Linux 2.6.10-1.766_FC3 #1 Wed Feb 9 23:06:42 EST 2005 i686 Changes since base revision: new_manifest [52a617d908ac6c4bb5b837ce5306f75155dc59ef] old_revision [168adf9537ff136c9b7fe7faad5991f92859390d] old_manifest [a9ee1d741b855fdcc0d038d64d913cef70da72f5] patch po/monotone.pot from [10e6d7cbad87eaa0dbe35c803cafa371567f024b] to [0465f6ac8d09fac5938ac067747b179aca677b67] Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. -- started up on Linux 2.6.10-1.766_FC3 #1 Wed Feb 9 23:06:42 EST 2005 i686 command line: 'monotone', 'drop', 'gsl-1.4' set locale: LC_CTYPE=en_US.UTF-8, LC_MESSAGES=en_US.UTF-8 initial path is /home/mlacage/sources/ns-80211/build searching for 'MT' directory with root '/' 'MT' not found in '/home/mlacage/sources/ns-80211/build' with '' removed search for 'MT' ended at '/home/mlacage/sources/ns-80211' with 'build' removed initializing from directory /home/mlacage/sources/ns-80211/build found working copy directory /home/mlacage/sources/ns-80211 options path is MT/options branch name is '' relative directory is 'build' local dump path is MT/debug setting dump path to MT/debug opening rcfile '/user/mlacage/home/.monotone/monotonerc' ... '/user/mlacage/home/.monotone/monotonerc' is ok skipping nonexistent rcfile 'MT/monotonerc' executing drop command options path is MT/options revision path is MT/revision loading revision id from MT/revision old manifest has 0 entries work path is MT/work checking for un-committed work file MT/work read rearrangement from MT/work 'gsl-1.4' prefixed to 'build/gsl-1.4' attribute map path is .mt-attrs adding build/gsl-1.4 to working copy delete set warning: SORRY -- 'drop somedir' is not going to work. warning: Revert and try 'find somedir -type f | xargs monotone drop' path_component.cc:53: invariant 'I(!null_name(*i))' violated ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone update failed
On Wed, May 11, 2005 at 08:24:36AM +0200, Jon Bright wrote: Nathaniel Smith wrote: On Tue, May 10, 2005 at 04:01:44PM -0700, David Brown wrote: This is trivial to do under windows. Having a shell open within a subdir of that directory, or any file within the dir opened will lock the directory. Should we be doing special checking for this? How do we handle it? Not really - David's right that it's trivial to lock a directory, but for these directories that we're creating and deleting ourselves, quickly, one after another, it's unlikely someone will cd into them. I thought the directory in question was on that already existed in the working copy; monotone can rearrange existing directories as part of update applying changes... -- Nathaniel -- .i dei jitfa fanmo xatra ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] error while dropping a directory
On Wed, May 11, 2005 at 09:35:01AM +0200, Mathieu Lacage wrote: [EMAIL PROTECTED] build]$ monotone drop gsl-1.4 monotone monotone: adding build/gsl-1.4 to working copy delete set monotone: warning: SORRY -- 'drop somedir' is not going to work. monotone: warning: Revert and try 'find somedir -type f | xargs monotone drop' *sigh* guess this warning here still isn't prominent enough :-) Your working copy is broken, until you 'monotone revert build/gsl-1.4'. In light of all the upcoming changes, I'm just going to disable delete_dir on mainline, we can re-enable it on whatever branch it gets fixed on... -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3 proposed changes to manifest/changeset format
On Wed, May 11, 2005 at 10:26:33AM +0800, Matt Johnston wrote: On Tue, May 10, 2005 at 03:26:40AM -0700, Nathaniel Smith wrote: Some smaller changes are in the offing, though: - First-class directory support If it'll fix dir dropping etc, sounds sane. Would this have consequences for making the root directory renamable? I'd like to seen renamable root directories eventually getting supported, as it seems to provide a convenient way to bring third party branches into a project (ie / of the hypothetical org.sqlite.sqlite branch gets renamed to sqlite/ when propagated to the net.venge.monotone branch). I'm interested in this feature too. This particular change doesn't have any direct effect, except that we might want to come up with some name for the root directory. (Ugh.) Or I guess we could later add a rename_root changeset op. (Ugh.) The sort of general goal is to make the revision/changeset/manifest format be as close a match as possible to the actual underlying domain; they should exactly record what really happened, and not record anything else. (For instance, unique persistent file identifiers do not actually exist in the model domain; they're something additional that a VCS might add to make its job easier. So, they shouldn't be in this format.) The meta-goal is to make this data neutral between different sorts of internal representations and algorithms that might want to run over it, so we can adjust those parts as needed. - Patches on delete_file: Currently, there's an assymmetry in the change_set format -- add_file foo is accompanied by patch foo from [] to [initial hash]. delete_file foo, on the other hand, is not accompanied by a patch foo from [final hash] to []. The reason for this is that such a hash would be redundant, but I think it's a decision worth revisiting. My gut feeling is that having the explicit patch to [] is likely to increase the chances of triggering invariants in edge/untested cases for change_set.cc, which is a good thing. Good point. - Attributes in manifests: this is a speculative idea, raised for discussion -- if we use basic_io for manifests, it becomes pretty straightforward to include file attributes (like .mt-attrs currently stores) directly into the manifest, if we want to. Presumably this would also involve adding set_attr and delete_attr type operations to changesets. One issue here is that without changes to the revision format, it'd be possible for a revision to have no changeset information yet differing old_ and new_ manifests, when only the attributes are altered? Yeah, right now manifests are technically redundant, since they are fully reconstructible from the changeset history. This seems like an important property to preserve. (Why have manifests at all, then? Because they provide end-to-end tree state integrity checking -- there might be bugs in the change set logic, but so long as the hash of the manifest of my checkout matches the hash of the manifest of your checkin, we can be certain we have the same tree. They're probably handy for things like partial pulls, too, where one wouldn't have access to full history...) -- Nathaniel -- Details are all that matters; God dwells there, and you never get to see Him if you don't struggle to get them right. -- Stephen Jay Gould ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] new selectors: earlier or equal and ?later
On Sat, May 07, 2005 at 11:05:11AM +0200, rghetta wrote:
The following patch adds two new selectors, e: and l: taking a date
expression and meaning respectively earlier or equal than and
strictly later than.
They can be used togheter to form a range [earlier, later). The later
end of the range is open.
Cool.
+static void
+sqlite3_normdate_fn(sqlite3_context *f, int nargs, sqlite3_value ** args)
What is this normdate stuff for? Sqlite allows = on strings, and it
compares as strcmp, which seems it should work perfectly well for
normalized ISO dates?
--- monotone.texi
+++ monotone.texi
@@ -2292,7 +2292,20 @@
@code{branch} certs where the cert value begins with @code{net.venge}.
@item Date selection
Uses selector type @code{d}. For example, @code{d:2004-04} matches
[EMAIL PROTECTED] certs where the cert value begins with @code{2004-04}.
[EMAIL PROTECTED] certs where the cert value begins with
[EMAIL PROTECTED] This selector also accepts expanded date syntax (see below).
[EMAIL PROTECTED] Earlier or equal than selection
+Uses selector type @code{e}. For example, @code{e:2004-04-25} matches
[EMAIL PROTECTED] certs where the cert value is less or equal than
[EMAIL PROTECTED]:00:00}. If the time component is unspecified,
+monotone will assume 00:00:00. This selector also accepts expanded date
+syntax (see below)
^ missing period
[EMAIL PROTECTED] Later than selection
+Uses selector type @code{l}. For example, @code{l:2004-04-25} matches
[EMAIL PROTECTED] certs where the cert value is strictly less than
[EMAIL PROTECTED]:00:00}. If the time component is unspecified,
+monotone will assume 00:00:00. This selector also accepts expanded date
+syntax (see below)
^ likewise
@item Identifier selection
Uses selector type @code{i}. For example, @code{i:0f3a} matches
revision IDs which begin with @code{0f3a}.
@@ -2325,6 +2338,37 @@
addresses, branch names, or date specifications. For the complete
source code of the hook, see @ref{Hook Reference}.
[EMAIL PROTECTED] Expanding dates
Thanks for documenting this!
-if (str.find_first_not_of(constants::legal_id_bytes) == std::string::npos
- str.size() == constants::idlen)
+if (str.find_first_not_of (constants::legal_id_bytes) ==
+ std::string::npos str.size () ==
constants::idlen)
^^ these are literal tabs. Please do not submit patches containing
tab characters?
(Among the other reasons to not use tabs, there's a fair amount of
noise in this patch from just this.)
--- testsuite.at
+++ testsuite.at
@@ -136,6 +136,54 @@
io.write(string.format(test_attr:%s:%s\n, filename, value))
end
+function expand_date(str)
If you want to test the behavior of the default hooks, I suggest using
RAW_MONOTONE instead of MONOTONE (there are several tests that do this
already). This is much better than copying the hook into the
testsuite, because if the standard version in monotone changes, then
we will be testing the version in the testsuite rather than the
version in monotone. Which would make the test kind of pointless :-).
-- Nathaniel
--
Eternity is very long, especially towards the end.
-- Woody Allen
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Merges and internal representation
On Tue, May 10, 2005 at 05:46:29PM +0100, [EMAIL PROTECTED] wrote: Nathaniel et al, With all the discussion on Codeville and weave representation recently, I just wanted to remind people that there are file formats (e.g. XML, other structured data formats) which are not particularly well suited to line based storage and merging; many SCMs like Clearcase have a pluggable architecture which allows files to be associated with a type manager responsible for knowing how to store, merge and annotate different types of files. It would be nice to ensure that any changes as a result of codeville discussion didn't prejudice the capability to support a type manager architecture in the future. Well, we'll still store and version arbitrary, uninterpreted binary blobs. The merge implementation is entirely client-side, and could be made as smart or stupid as one likes. It's not entirely clear what these tools would do; we could always in principle add back 3-way merge ancestor selection stuff for this use case, and hand off to an external 3-way merge tool, but, well, as we've discovered, 3-way merge just doesn't work that well. (Two merge is always easy to support, as well, and for some of these formats that might be all that's possible anyway...) Perhaps people will start writing external format-specific codeville-merge tools :-). In any case, while the proposed changes do move us a bit away from being able to support such tools (if we pull out the 3-way merge ancestry selection code), they in no way rule it out, and since we don't support it right now anyway, it's not really a regression :-). -- Nathaniel -- Details are all that matters; God dwells there, and you never get to see Him if you don't struggle to get them right. -- Stephen Jay Gould ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] sqlite versus metakit
On Wednesday 11 May 2005 07:33, Richard Levitte - VMS Whacker wrote: berkus What do you think, is it worth a shot? berkus berkus ps/ http://www.equi4.com/metakit On a very personal level, I find the note about the library working on VMS interesting. That's about the only compelling thing I can find. I'm not sure if that makes a shift worth the while. Yeah after looking at the thing for a bit more i think sqlite is pretty good for what its used now. Was just peeking in ;) -- Best regards, Stanislav Karchebny Skype name: berkus Get skype for free from www.skype.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] zsh auto-completion
On Tue, May 10, 2005 at 10:49:48PM -0400, Joel Reed wrote: snip With formatting specifications for monotone automate I could improve the completion code a good bit around files presented for drop,revert,rename,etc. also i should add, i need a way to limit monotone automate inventory to the current working directory and be non-recursive. jr ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] .mt-ignore and .cvsignore files
Hi,
I've just made a patch to support the '.mt-ignore' file. It's a simple
file which contains one regular expression per line. Do you have any
objections against making it a standard way to describe ignored files?
I also attached Lua code to support '.cvsignore' files. It's handy when
someone is tracking project which has upstream stored in CVS. I think it
could be put in the contrib dir.
bye,
Martin
#
# patch lua.cc
# from [42373a056c2983c5f3d6303eb33c8c8ed88b2aae]
#to [f4eebc463e2ceb11a5b39e09e64b70018709c13f]
#
# patch std_hooks.lua
# from [598cbe38dd953fe9133e5151caeae60e0d07ea95]
#to [fab68a03718ff24159000c76c13c3f7c5888f5ef]
#
--- lua.cc
+++ lua.cc
@@ -18,6 +18,7 @@
#include boost/lexical_cast.hpp
#include boost/filesystem/path.hpp
#include boost/filesystem/operations.hpp
+#include boost/regex.hpp
#include set
#include map
@@ -155,6 +156,17 @@
lua_pushnumber(L, process_sleep(seconds));
return 1;
}
+
+ static int
+ monotone_regex_search_for_lua(lua_State *L)
+ {
+const char *re = lua_tostring(L, -2);
+const char *str = lua_tostring(L, -1);
+boost::cmatch what;
+
+lua_pushboolean(L, boost::regex_search(str, what, boost::regex(re)));
+return 1;
+ }
}
@@ -182,6 +194,18 @@
lua_register(st, wait, monotone_wait_for_lua);
lua_register(st, kill, monotone_kill_for_lua);
lua_register(st, sleep, monotone_sleep_for_lua);
+
+ // add regex functions:
+ lua_newtable(st);
+ lua_pushstring(st, regex);
+ lua_pushvalue(st, -2);
+ lua_settable(st, LUA_GLOBALSINDEX);
+
+ lua_pushstring(st, search);
+ lua_pushcfunction(st, monotone_regex_search_for_lua);
+ lua_settable(st, -3);
+
+ lua_pop(st, 1);
}
lua_hooks::~lua_hooks()
--- std_hooks.lua
+++ std_hooks.lua
@@ -74,7 +74,25 @@
if (string.find(name, /SCCS/)) then return true end
if (string.find(name, %.pyc$)) then return true end
if (string.find(name, %.pyo$)) then return true end
- return false;
+
+ -- read the '.mt-ignore' file:
+ if (ignored_files == nil) then
+ ignored_files = {}
+ local i = 1
+ for line in io.lines(.mt-ignore) do
+ ignored_files[i] = line
+ i = i + 1
+ end
+ end
+
+ for i = 1,table.getn(ignored_files) do
+ local line = ignored_files[i]
+ if (regex.search(line, name)) then
+ return true
+ end
+ end
+
+ return false
end
function glob_to_pattern(glob)
local pattern
-- escape all special characters:
pattern = string.gsub(glob, ([%^%$%(%)%%%.%[%]%*%+%-%?]), %%%1)
-- convert the glob's ones to pattern's:
pattern = string.gsub(pattern, %%%*, [^/]*)
pattern = string.gsub(pattern, %%%?, .)
return pattern
end
function ignore_file(name)
local dir, pat1, pat2
dir = string.gsub(name, /[^/]+$, /)
if (dir == name) then dir = end
pat1 = ^ .. glob_to_pattern(dir)
for line in io.lines(dir .. .cvsignore) do
pat2 = glob_to_pattern(line) .. $
if (string.find(name, pat1 .. pat2)) then return true end
end
return false
end
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Handling the debian files
On Wed, May 11, 2005 at 03:42:24PM +0200, Tomas Fasth wrote: Nathaniel Smith skrev: So it's good if I continue to add changelog entries with my name on them during release, for instance? It's not ideal, I admit that. This is because the debian files is Debian business, really. It's hard for a Debian package maintainer to maintain a package if he/she is restrained by upstream already providing a debian folder and use dash-digit versions in unofficial debian package builds. It really will cause trouble for end users sooner or later because of the version namespace conflict and possible confusion about who's the actual maintainer and where to send bug reports. Right, this is what I'm worried about. But I don't have a better solution, either, because I can never commit myself to a certain timeframe, especially not a tight one, because of my own business, my wife and kids, and also the other Debian packages I have to maintain (hm, just a few, really). Nod, right, understandable. May I suggest a compromise? You do your releases as before. But when a new upload has been prepared for the Debian archive, could you then replace the unofficial package files with the corresponding official ones? Or maybe not. We could then just give the visitors a pointer to the official Debian archive. You still need to change your use of dash-digit debian package version postfixes. Really. May I suggest a change to dash-zero? Debian package version postfix always start at dash-one. Sure. How does one go about doing this? My debian package-fu is not strong. -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] .mt-ignore and .cvsignore files
On Wed, May 11, 2005 at 01:33:56PM +0200, Martin Dvorak wrote: Hi, I've just made a patch to support the '.mt-ignore' file. It's a simple file which contains one regular expression per line. Do you have any objections against making it a standard way to describe ignored files? Please also document this in monotone.texi, and add a test for it? -- Nathaniel -- /* Tell the world that we're going to be the grim * reaper of innocent orphaned children. */ -- Linux kernel 2.4.5, main.c ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Handling the debian files
* Tomas Fasth: But I don't have a better solution, either, because I can never commit myself to a certain timeframe, especially not a tight one, because of my own business, my wife and kids, and also the other Debian packages I have to maintain (hm, just a few, really). Maybe with a co-maintainer, it would be possible to do things in a more consistent time frame? In this case, I'd suggest to remove the debian/* files from the net.venge.monotone branch, and keep the official Debian package sources on a separate branch. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3 proposed changes to manifest/changeset format
* Matt Johnston: If it'll fix dir dropping etc, sounds sane. Would this have consequences for making the root directory renamable? I'd like to seen renamable root directories eventually getting supported, as it seems to provide a convenient way to bring third party branches into a project I'm not sure if this is going to work. You could end up with multiple instances of the same file, which will be rather painful to deal with (if I'm not mistaken). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3 proposed changes to manifest/changeset format
On Thu, May 12, 2005 at 12:13:11AM +0200, Florian Weimer wrote: * Matt Johnston: If it'll fix dir dropping etc, sounds sane. Would this have consequences for making the root directory renamable? I'd like to seen renamable root directories eventually getting supported, as it seems to provide a convenient way to bring third party branches into a project I'm not sure if this is going to work. You could end up with multiple instances of the same file, which will be rather painful to deal with (if I'm not mistaken). How do you mean? I don't see how it's different from any other sort of directory renaming. It does require directory suturing to be useful, though. Hmm. (Because for the project-combination case to work, you need to be able to unify two root directories; and if root directories are directories like any other, this means directory suturing needs to work.) (suturing is taking two logically distinct files or directories, and melding them into a single one.) -- Nathaniel -- When the flush of a new-born sun fell first on Eden's green and gold, Our father Adam sat under the Tree and scratched with a stick in the mould; And the first rude sketch that the world had seen was joy to his mighty heart, Till the Devil whispered behind the leaves, It's pretty, but is it Art? -- The Conundrum of the Workshops, Rudyard Kipling ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone tests failed - testsuite logs
On Tue, May 10, 2005 at 11:09:12PM +0200, Andreas Otto wrote: Hello, I've run the tests of monotone on two of my servers. One has a Suse 9.1 und the other has Suse Linux 9.3. Both tests have problems. Perhaps the logs will help. Thanks! None of these seem to actually be bugs in monotone: - 4 of the failures in each case are because you ran the testsuite as root, and apparently that makes cvs cranky. (we use cvs in several tests of monotone's cvs_import functionality.) - 1 failure is because your Suse 9.3 box doesn't have 'patch' installed, which causes the test that makes sure monotone's 'diff' output is compatible with 'patch', to fail. - 1 failure is very strange. It looks like we ran something like: $ mkdir /tmp/scratch-space; cd /tmp/scratch-space $ mkdir foo/ $ mv foo/ bar/ and the mv failed with no such directory bar/. I don't really understand why this would be so, unless Suse 9.3 has some sort of strange mv command? -- Nathaniel -- ...All of this suggests that if we wished to find a modern-day model for British and American speech of the late eighteenth century, we could probably do no better than Yosemite Sam. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone update overwrites local changes
One option is to punt like CVS does and refuse to update unless B/F is moved away. More useful would be to initiate a two-way-merge between the repository version and what's already there. The latter is already done when I do monotone add B/F before updating. (A middle-of-the- road solution would be to punt with a reminder that one can either move F away or add it to get merging behaviour.) How about just skip the file and keep going, perhaps with a warning like preserving existing file Then you can do status and diff, to see what state the offending file is in, and revert it or commit it as a change to A/F or whatever else might be sensible. I had done something along these lines long ago on the ...noclobber branch but that was never merged and has pretty much been clobbered itsself by all the changes that have happened since. Personally I would really like to have this functionality, perhaps controlled by a hook to allow for. - clobber existing files - preserve existing files - fail on existing files I also think that an option for checkout to do the same might be nice, although 'echo $REV MT/revision' can be used as a poor approximation. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtbrowser - Text based browser for source control
On Sat, May 07, 2005 at 01:35:27PM +0200, Henry Nestler wrote: For some simple browsing in revisions database, I wrote this tool from shell script. It use only dialog and some simple shell tools (cut, cat echo, head, tail, sort, ...). Is not full futured. I wrote this only in some hours today. Is very simple to handle and fast. The longest time it need to get the certs of revision. Neat. Would you like to stick it in contrib/, so it's available to people? or do something else? -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: zsh auto-completion
On Wed, May 11, 2005 at 10:01:22PM -0400, Joel Reed wrote: hmm, the Plo, Po, and .dirstamp files are in .deps/ and are used by automake for dependency tracking. perhaps just adding: if (string.find(name, /autom4te.cache/)) then return true end if (string.find(name, /.deps/)) then return true end Good idea. Done. -- 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
