[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)
From: |
Christof Petig |
Subject: |
Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?) |
Date: |
Wed, 30 Aug 2006 09:18:56 +0200 |
User-agent: |
Thunderbird 1.5.0.5 (X11/20060728) |
Markus Schiltknecht schrieb:
> If we store the original RCS version as a file attribute, how can the
> end-user query what CVS files he got with a given MTN revision? Where
> could we save 'per revision' information? (The 'all CVS commits were
> between 27/08/2006 15:42:13 and 27/08/2006 15:42:19' or even: 'this
> revision overlaps in CVS with MTN revision 359a3f2...' things)?
If I understand this requirement correctly that's what I designed
automate get_sync_info for (which parses the file and any following
delta certificates).
And I plan for a command to synchronize the sync file contents after a
push (which has to do a commit (and perhaps update))
> And can we somehow ensure, that the file attribute gets deleted after
> the first MTN commit? It seems irritating to have the latest RCS version
> attached to all files after that.
Indead. That's why i chose certificates the first time ... see below
> (My understanding is that such information would much better fit into a
> per revision cert, instead of file attributes, which sounds somewhat
> like a hack. But I guess compressing or even delta-compressing certs is
> not an option, huh?)
I went this path in cvssync1 and it proved to be fragile (imagine a 3000
revision spanning delta certificate chain) and slow.
I really was glad to have found a file based approach in cvssync2, which
nicely covers compression, delta encoding and readability. Even if this
was at the cost of asymmetry (pull can change this file, push can't)
I consider the current head of cvssync.refactor
(f32f0d3bfd4dbeac8d2ede26ec32df84c2009979) as finished concerning pull,
so you might give it a try (even if push and takeover functionality is
turned off and the manual not rewritten, yet)
Christof
Syntax:
mtn_cvs --mtn=binary [--branch dest] pull [repository module [branch]]
e.g.
mtn_cvs --mtn=../mtn --branch somewhere pull
cvs.manuproc.berlios.de:/cvsroot/manuproc ManuProCBase
and then
mtn_cvs --mtn=../mtn --branch somewhere pull
signature.asc
Description: OpenPGP digital signature
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), (continued)
- 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
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Markus Schiltknecht, 2006/08/29
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Nathaniel Smith, 2006/08/29
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?),
Christof Petig <=
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Daniel Carosone, 2006/08/23
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Christof Petig, 2006/08/25
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Christof Petig, 2006/08/25