On Sun, Aug 27, 2006 at 10:29:40PM -0700, Zack Weinberg wrote:
In order to do generic exhaustive testing of workspace migration I
need an exhaustive list of all the state that can be held in a
workspace, i.e. all the changes-relative-to-the-base-revision that are
somehow stored there. This is
On Sun, Aug 27, 2006 at 11:07:55PM -0700, Zack Weinberg wrote:
Well, sure. But if you recall, this discussion was originally about
the not-exactly-static Linux/glibc binary on the website...
Yeah, specifically about problems where the vagaries of the specific
system might not match some of the
On 8/27/06, Nathaniel Smith [EMAIL PROTECTED] wrote:
On Sun, Aug 27, 2006 at 10:29:40PM -0700, Zack Weinberg wrote:
In order to do generic exhaustive testing of workspace migration I
need an exhaustive list of all the state that can be held in a
workspace
...
I'm not sure if ignore list
Lapo Luchini schrieb:
file_id 03cfd743661f07975fa2f1220c5194cbaff48451
is ::ext::[EMAIL PROTECTED]:/usr/local/cvsroot's module/subdir/A 1.17.0.5
and .../A 1.18
and .../B 1.2
But file attributes are revision-specific, they aren't on the fild_id,
are they?
(attributes as in mtn attr
On Mon, Aug 28, 2006 at 12:01:58AM -0700, Zack Weinberg wrote:
On 8/27/06, Nathaniel Smith [EMAIL PROTECTED] wrote:
On Sun, Aug 27, 2006 at 10:29:40PM -0700, Zack Weinberg wrote:
In order to do generic exhaustive testing of workspace migration I
need an exhaustive list of all the state that
Nathaniel Smith wrote:
As Lapo pointed out, I think you might have misunderstood... I didn't
mean to attach this information to file_id's. I meant to attach it
to files in the tree, using the attr mechanism:
http://venge.net/monotone/docs/File-Attributes.html
Such attrs are stored and
Nathaniel Smith schrieb:
On Sun, Aug 27, 2006 at 12:07:33AM +0200, Christof Petig wrote:
The main reason for me to use a special file format is to have the
information in one place (which also applies to attributes) and to base
some logic upon whether this file was changed since the last
Nathaniel Smith wrote:
...I think that's it. We also use _MTN/debug as a place to drop crash
logs, and _MTN/tmp/ as a temporary store while applying updates, but
neither of these hold state in the sense that we write them in one
run, and read them in another.
It might be worth bearing in
Markus Schiltknecht [EMAIL PROTECTED] writes:
[...]
Hm, but why store that per file? Isn't the user more interested in
questions like 'what CVS revision is this MTN revision equal to?'.
That doesn't make sense without specifying the file. CVS versions
files independently, so there is no
Bruce Stephens wrote:
That doesn't make sense without specifying the file. CVS versions
files independently, so there is no single CVS revision for a coherent
checkout (almost always, anyway).
Sorry, I should have made that clearer. I meant to store something like:
file_foo.txt 1.75
Markus Schiltknecht [EMAIL PROTECTED] writes:
[...]
Sorry, I should have made that clearer. I meant to store something like:
file_foo.txt 1.75
file_bar.txt 1.9
TODO 1.1
README 1.5
per revision. Additionally one could save infos like: 'all CVS commits
were between 27/08/2006 15:42:13 and
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Sun, 27 Aug 2006 09:27:22 +0200 (CEST), Richard
Levitte - VMS Whacker [EMAIL PROTECTED] said:
I've figured out what happened, btw. This is part of my build if
snapshot Debian packages, and to do those, I propagate nvm,
12 matches
Mail list logo
