Hi,
Christof Petig wrote:
For re-syncing the number of the last revision which is known to CVS is
quite interesting (e.g. this content is a modified revision 1.3). So I
store revision and (a part of) the sha1 sum in cvssync3.
Of what sha1 sum? Where do you store that? You don't store *that* in the
file attributes, do you?
Actually the attibute base cvssync code in nvm.cvssync.refactor is ready
and working (preliminary 'documentation' is at the end of
mtn_cvs/CVS_prot).
I'll check that documentation out...
Actually your manifest comment is quite similar to the certificates I
used with cvssync1. I think that attributes are really a good way to
store sync information (you convinced me of that)
Was that really me? :-)
If I were to freely choose a mechanism which clearly indicates whether a
file is in sync I would _modify_ the release number instead of dumping
it (e.g. "1.3"->"1.3+")
Hm.. yes, that's a very nice idea. Using delta compression, this won't
cost more than changing it.
What I fear is, that this might become a huge attribute value one day
(read: when importing large repositories).
That hack works well in practice. And it's scaleable to cover a lot of
synchronization partners in one tree at once.
Okay.
You are circumventing my major point against file attributes (which is
that they are inherited by subsequent commits and shown in diffs) by
saying you don't store *the* RCS release number of the file, but the
complete history. Relabeling the field to mean: the file is based on
these RCS versions.
But still my concern applies somewhat: the file which is exactly equal
to the one in CVS would have the same attribute values as any other file
derived from that one (in monotone).
Plus: that might fit well for CVS, but how about subversion or git. Do
you really want to store:
"r1 > r2 > r3 > r4 > r5 > r5 .... r3267 > r3268 > r3269" in a file
attribute value for the root directory? That seems messy to me. And it
would show up in a diff.
Regards
Markus
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel