[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (p
From: |
Nathaniel Smith |
Subject: |
cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)) |
Date: |
Mon, 28 Aug 2006 00:43:13 -0700 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
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 revision.
>
> Yeah file attributes appeal to me, too (on second thought) (but that
> does not solve the "push can't change this information" problem).
>
> Do file attributes scale well enough? (since they are part of the
> revision information, I would need three per file ...)
What do you use the 3 for?
They are pretty efficient -- most importantly, revisions only describe
changes in attributes, and they are stored inside the roster, which is
already delta-compressed as a whole. I can't think of any reason why
this would be noticeably less efficient than putting the same
information in a file.
> I wrote a command to retrieve the whole sync information per revision.
The manifest includes all file attributes; you can simply read them
all off of there.
> And I also had svn on my mind when I designed that feature.
Not sure what you mean here. Surely for svn synchronization, you only
need to know svn's whole-repo version number, plus where in the svn
namespace this mtn branch belongs? (I.e., "this mtn revision
corresponds to the /branches/foo/ subtree of svn revision 1234".)
> My feeling is that I follow my chosen way further and see where I get
> to. Changing the storage form is not that difficult.
Nod.
-- Nathaniel
--
In mathematics, it's not enough to read the words
you have to hear the music
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), (continued)
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Christof Petig, 2006/08/25
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Markus Schiltknecht, 2006/08/25
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Christof Petig, 2006/08/25
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Nathaniel Smith, 2006/08/25
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Christof Petig, 2006/08/25
- [Monotone-devel] Re: big repositories inconveniences (partial pull?), Lapo Luchini, 2006/08/26
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Christof Petig, 2006/08/28
- cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)),
Nathaniel Smith <=
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Christof Petig, 2006/08/28
- Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Nathaniel Smith, 2006/08/28
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Nathaniel Smith, 2006/08/27
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Daniel Carosone, 2006/08/27
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Markus Schiltknecht, 2006/08/28
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Bruce Stephens, 2006/08/28
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Markus Schiltknecht, 2006/08/28
- [Monotone-devel] Re: big repositories inconveniences (partial pull?), Bruce Stephens, 2006/08/28
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Markus Schiltknecht, 2006/08/28
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Nathaniel Smith, 2006/08/28