[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: sha1sum doesn't match revision number
From: |
Bruce Stephens |
Subject: |
[Monotone-devel] Re: sha1sum doesn't match revision number |
Date: |
Fri, 02 Sep 2005 12:44:24 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
"Todd A. Jacobs" <address@hidden> writes:
[...]
> But the current manifest contains only the current file set, right?
Yes.
> [...] If I understand the purpose of the manifest correctly, then
> searching it for an historical hash might not be very useful unless
> I checked each previous revision of the manifest until I found a
> match.
I think that's what you'd have to do, yes.
[...]
> But that's okay. Generally speaking, one would be looking for the
> most recent revision in which a given version of the file
> exists. The use case you're pointing out, where it matters which
> revision a particular file was part of, gets us back to the earlier
> thread of keywords, and that wasn't where I was going this time
> around. :)
"Most recent" isn't necessarily usefully defined in something like
monotone. However, I can see that in practical situations you could
probably come up with something.
> I think the more-general use case that monotone isn't currently
> addressing is the case where *loosely-associated* files (LaTeX
> documents, rc files, web sites, etc.) are being maintained in the
> same database, rather than tightly-coupled ones (such as the
> codebase for a single application).
I guess that's true. But that's also true of most of the recent
systems: they're explicitly about managing changesets. You could
store each file in a separate branch (in the same database). That
would decouple the files. (I don't think it would help for this, but
it might be a more logical organisation, if you really aren't
interested in managing the files as a unit.)
>>It may be useful to go from a hash to a list of all revisions which
>>contain it (together with the filenames, since the same contents may
>>be in files with different names, of course), but I don't think
>
> I agree, that would be extremely useful.
All we need is something like an SQL database; then we could have a
table: (filename, hash, revision). Or maybe (filename, hash,
manifest), and (manifest,revision) separately.
That strikes me as potentially handy for doing filename lookups, too;
now and again I do "find ..." on our CVS repository to find where a
file should be, or once was. I could see that being potentially
useful in monotone.