monotone-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]