Stephen Leake, 2007-07-20:
Christian Ohler <[EMAIL PROTECTED]> writes:
Christian Ohler, 2007-07-08:
In the mtn-has-basic-io-inventory case, it should be possible to speed
this up somewhat by passing the file name we're looking for to mtn
automate inventory. This will avoid gen
Stefan Monnier, 2007-08-23:
I know VC is not very well suited to current revision control systems, but
some of its functionality does make sense and is convenient (typically: show
diffs made to the current buffer's file, indicate the revision control
system used for the current buffer's file in
Christian Ohler, 2007-07-08:
In the mtn-has-basic-io-inventory case, it should be possible to speed
this up somewhat by passing the file name we're looking for to mtn
automate inventory. This will avoid generating the entire inventory.
Turns out that this is not possible: mtn aut
Nathaniel Smith, 2007-05-30:
In my world, the reason we need partial pull is that the total history
size of a project grows without bound. Therefore, for very large and
old projects (Linux kernel, *BSD, Mozilla, gcc, glibc, maybe a few
others), the full history database may be many times larger
Lapo Luchini, 2007-05-26:
Space is not the scarce resource here (well, not the most important one,
at least, IMHO): time is.
Pull time is not only a question of size, it's also (mainly?) a question
of the time taken by the multiple hash and signature verifications.
Ok. Still, verifying signat
Thomas Keller, 2007-05-25:
I'm not completly in this topic, so I might be perfectly wrong, but
wouldn't it be possible to just fetch the revision_id graph and leave
out revision texts, roster and file data for gap/unfetched revisions,
just mark them in a special way?
Or how about simply tran
Thomas Moschny, 2007-04-30:
Christian Ohler wrote:
I don't think this is the only valid way of looking at basic_io.
Stanzas are separated by an empty line; what's wrong with (or "not
stable" about) relying on that? You're suggesting to discard this
information that is
Stephen Leake, 2007-05-10:
Then the stanza should start with 'status', since there needs to be a
line that reliably starts a stanza
Not really. Manifests also have two alternative forms of stanzas, one
starting with 'file', one starting with 'dir'.
Christian.
Stephen Leake, 2007-04-30:
That requires 'oelp', which I don't have.
Sorry about that. Just use elp instead (included with Emacs).
Christian.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monot
Thomas Moschny, 2007-04-29:
On Saturday 28 April 2007, Stephen Leake wrote:
Is there some documentation on these requirements for basic_io
parsers? I found basic_io.hh and luaext_parse_basic_io.cc; not many
comments :). I searched the wiki for "basic_io" and "basic io"; I
found BasicIoFormaliza
Stephen Leake, 2007-04-24:
Thomas Keller <[EMAIL PROTECTED]> writes:
b) Since we already have those data in place: I'd vote for including
the old and new fileid in the stanzas (where applicable)... this saves
additional calls to automate identify or automate get_manifest_of for
the interface p
Thomas Keller, 2007-04-26:
Stephen Leake schrieb:
>
I'm not clear what the rationale is for the node ids; what subsequent
commands would use them?
F.e. automate get_file (obviously there is a version available now which
takes the file path and revision_id).
Just to be clear, automate get_f
Thomas Moschny, 2007-04-12:
On Tuesday 03 April 2007, Christian Ohler wrote:
Pressing C-x V = will bring up the tree diff buffer. (What monotone
calls a "workspace" is called a "tree" in DVC.) This buffer shows the
list of all modified files in the tree as well as the d
Daniel Carosone, 2007-04-24:
On Tue, Apr 24, 2007 at 12:09:50AM -0700, Nathaniel Smith wrote:
On Tue, Apr 24, 2007 at 02:51:35AM -0400, Stephen Leake wrote:
For me, the primary use case for Emacs DVC monotone is to get a list
of files that need attention; most of the time, that's a very small
Bruce Stephens, 2007-04-12:
Bruce Stephens, 2007-04-11:
That is, I want to see changes between my workspace and some revision
other than the workspace's base revision.
[...]
I was imagining that C-x V = might do this with a prefis argument, but
on reflection I guess that wouldn't make so mu
Bruce Stephens, 2007-04-11:
Christian Ohler <[EMAIL PROTECTED]> writes:
DVC, an Emacs package that provides a generic interface to distributed
version control systems, now has a monotone backend. This backend is
called xmtn.
I like it so far.
Thanks.
A feature I feel I want
Derek Scherger, 2007-04-04:
$ tar ztvf dvc-snapshot.tar.gz | head -n1
drwxr-xr-x moy/synchron 0 2007-04-03 19:25 dvc-snapshot.tar.gz/
Apparently the top-level directory in the tarball has the same name as
the tarball so untarring it overwrites the tarball.
Oops. I agree this isn't how i
DVC, an Emacs package that provides a generic interface to distributed
version control systems, now has a monotone backend. This backend is
called xmtn.
See http://download.gna.org/dvc/ for additional information on DVC.
Mailing lists can be found at http://gna.org/projects/dvc .
Much of DVC's
get rid of related bugs, such as "mtn ls unknown" aborting when some
files are missing.
Christian Ohler.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
s in fact looking at _MTN, the code
ultimately aborts with the above assertion.
I hope this helps.
Christian Ohler.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
There's a pretty serious bug in automate stdio in mtn 0.31 and mainline.
Under certain circumstances, mtn gets confused reading its input and
processes a command that is different from what was sent on stdin.
I believe the attached (one-line) patch fixes this. Unfortunately, I
see no easy wa
21 matches
Mail list logo
