Daniel Carosone wrote:
Nope. It doesn't really change from one revision to the next, does it?
Uhm, right, that's yet another case. But that would need 'per branch' or
even 'per repository' attributes, which we don't have. But there are CVS
informations which change per revision.
At least,
Nathaniel Smith schrieb:
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
On Thu, Sep 07, 2006 at 07:55:06PM +0200, Christof Petig wrote:
Nathaniel Smith schrieb:
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
On Thu, Sep 07, 2006 at 07:55:06PM +0200, Christof Petig wrote:
Proposal:
attributes cvs-revision 1.2
[cvs-keyword-expansion -kb] (-kk is standard like in CVS?)
looks fine. (is it really rcs-revision?)
But where to store module path and root address?
As cvs-root and cvs-path attrs on
Nathaniel Smith schrieb:
Proposal:
attributes cvs-revision 1.2
[cvs-keyword-expansion -kb] (-kk is standard like in CVS?)
Should be either cvs:revision or mtn:cvs-revision, following the
namespace:name convention. It looks like cvs2svn uses
cvs2svn:cvs-revnum, which doesn't strike me
Daniel Carosone schrieb:
On Thu, Sep 07, 2006 at 07:55:06PM +0200, Christof Petig wrote:
Proposal:
attributes cvs-revision 1.2
[cvs-keyword-expansion -kb] (-kk is standard like in CVS?)
looks fine. (is it really rcs-revision?)
yes it is rcs-revision but cvs:rcs-revision sounds ugly.
Hi,
Please excuse the longish mail. I got carried away a little with two or
three thoughs...
Christof Petig wrote:
Now I have to come up with a coding for push certificates (which, in the
past were a simple xdiff to a specified .mtn-sync-cvs file). And I have
to think about flagging a
Daniel Carosone wrote:
That's exactly how attr's are stored, which is why we propose to use
them for this..
So, good ideas, and luckily they're already in use! :)
Heh, cool. You mean, file attributes are stored in the manifest... can I
store 'revision attributes' there? Like the ones in
On Fri, Sep 08, 2006 at 09:12:14PM +1000, Daniel Carosone wrote:
Or even better: use the manifest to store that information...
That's exactly how attr's are stored
It's how attr's are represented.
I had deliberately omitted mentioning the 'minor' detail that
manifests are actually
Markus Schiltknecht schrieb:
Heh, cool. You mean, file attributes are stored in the manifest... can I
store 'revision attributes' there? Like the ones in sample I mentioned:
CVS_server_path :pserver:[EMAIL PROTECTED]:/foo/cvsroot
that's the root, isn't it. The server path is in the file
Christof Petig wrote:
that's the root, isn't it. The server path is in the file Repository.
Right, it's the CVSROOT, sorry.
actually the last plan was to store it as an attribute called
cvs:server_path attached to the root directory .
ISTM that it's not an attribute of the root
On Friday 08 September 2006 13:12 Daniel Carosone wrote:
On Fri, Sep 08, 2006 at 11:25:38AM +0200, Markus Schiltknecht wrote:
To understand how certs are stored, I took a look at schema.sql and
found:
CREATE TABLE revision_certs
(
hash not null unique, -- hash of remaining fields
On Fri, Sep 08, 2006 at 06:50:28PM +0200, Markus Schiltknecht wrote:
Christof Petig wrote:
that's the root, isn't it. The server path is in the file Repository.
Right, it's the CVSROOT, sorry.
actually the last plan was to store it as an attribute called
cvs:server_path attached to the
On Fri, Sep 08, 2006 at 10:07:32AM +0200, Christof Petig wrote:
(This way my sync namespaces still exist. E.g. synching with two
different cvs servers is still possible cvs:revision vs cvs2:revision)
yeah, that's good.
Note that if we allow this on subdirectories rather than only the root
Nathaniel Smith schrieb:
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
15 matches
Mail list logo
