monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] basic_io inventory (was xmtn: Emacs integration via


From: Thomas Keller
Subject: Re: [Monotone-devel] basic_io inventory (was xmtn: Emacs integration via DVC)
Date: Thu, 26 Apr 2007 09:22:36 +0200
User-agent: Thunderbird 2.0.0.0 (Macintosh/20070326)

Derek Scherger schrieb:
> The amount of interest is encouraging though, and considering that
> apparently everyone who uses inventory has experienced the problems with
> the old format and wants to see it fixed maybe we should actually do
> something about it. ;)

Yay, lets do it!

>> Wrt the new format, the following open questions remain:
>>
>> a) should there be a more explicit rename marker in the new format than
>> the rather implicit node ids? I think, yes, because for the
>> path-/depth-restricted output we can't tell the exact state of the item
>> (is it only dropped, or actually renamed?)
> 
> I don't think this is correct. Listing either old or new name of a
> renamed path will include the *node* in a restriction and including the
> node will list both old and new names in the resulting inventory output.

I've actually tested this out before and it is correct if a rename
happens in the same directory. But, AFAIR, if you move / rename a file
to a different directory you do _not_ get the renamed node outputted as
well. Maybe we should fix that then?

> I also don't think it would be a terrible idea to list a bunch of path
> status flags like added/dropped/renamed. However, note that it's
> possible to see more than one of these, since a path can describe a node
> that has been dropped or renamed out and also another node that was
> subsequently added or renamed in, etc.

Of course, not a problem, as one always knows that added, renamed_to are
new_node states and dropped, renamed_from are old_node states.

>> 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 programmer.
> 
> you're talking about sha1 file_ids eh? (i.e. not the node_id's that are
> already listed)? it would be trivial to list them and I don't see real
> down-side to doing that. if you aren't interested in them then ignore them.

Yep, I'm interested in the content hashes. But apparently some people
think this would generate too much overhead. I have no strong personal
feelings for/against that feature, so its entirely optional.

Thomas.

-- 
ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz
> Guitone, a frontend for monotone: http://guitone.thomaskeller.biz
> Music lyrics and more: http://musicmademe.com




reply via email to

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