[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: sha1sum doesn't match revision number
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] Re: sha1sum doesn't match revision number |
Date: |
Sat, 3 Sep 2005 02:42:15 -0700 |
User-agent: |
Mutt/1.5.9i |
On Fri, Sep 02, 2005 at 12:44:24PM +0100, Bruce Stephens wrote:
> "Todd A. Jacobs" <address@hidden> writes:
> > 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.
You can do some strange and crazy hacks, if nothing else:
$ FID=`sha1sum myfile`
$ monotone automate ancestors `cat MT/revision` \
| monotone automate toposort address@hidden | tac \
| while read REV; do
if monotone cat revision $REV | grep -q $FID; then
echo "$FID was touched in rev $REV"
fi
done
This will print one line for each revision that either created or
removed a file with the given hash, in some plausible (history
respecting) order.
> >>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.
That would indeed be handy. History searching is, in general, an
interesting feature for a VCS to have -- searching for old paths,
searching for old text (history-sensitive grep), grepping through
changelogs, etc. Mercurial and I guess FastCST both make some
interesting efforts in this area; I would certainly not object if
people wanted to add similar features to Monotone, they're rather
handy.
-- Nathaniel
--
"But suppose I am not willing to claim that. For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."