[Top][All Lists]

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

Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconvenience

From: Christof Petig
Subject: Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?))
Date: Fri, 08 Sep 2006 10:07:32 +0200
User-agent: Thunderbird (X11/20060728)

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. Perhaps it is
as good as "cvs:file-revision" (which would be the exact term compared
to "git:revision" on the root directory)

(This way my sync namespaces still exist. E.g. synching with two
different cvs servers is still possible "cvs:revision" vs "cvs2:revision")

>> But where to store module path and root address?
> As cvs-root and cvs-path attrs on the parent directory.  

I didn't believe it possible (given that execute and binary attributes
do not make sense on directories).

> Note that if we allow this on subdirectories rather than only the root
> directory, we might facilitate modules behaviour. Different cvs-path
> attrs would also allow monotone to rename directories but keep the
> original cvs paths.  I suppose if no cvs-path attr exists you can add
> the current dir name to the path of the parent, or just insist every
> dir has a cvs-path (otherwise its considered not tracked by cvs).

good point! (having parts not tracked by cvs I never imagined)

> If we also allow different cvs-root attrs through the tree, you might
> track multiple cvs projects with merge_into_dir style assembly.
> Probably it's best to avoid that, and at least encourage people to
> instead treat a separate CVS branch like a vendor branch, and
> merge_into_dir into their monotone tree.

Ugh. I don't want to go that way (e.g. connect to different servers to
update a tree)

>> And what about svn and git information? 
> similar svn- and git- revision attrs on the top directory, too?  How
> do you intend tracking svn's branches (the naming convention ones, not
> the ancestry aspect)?

(I did not yet grasp the meaning of svn branches and expected it to work
similar to cvs branches)

>> I was glad to have a single way to handle all external
>> synchronisation information in one central place.
> What happens if multiple such are on the same directory?  Someone's
> bound to try using such a monotone repository like tailor to feed
> changes between other systems.  It would be great if it worked, but
> I'm not sure this is your goal :)

Synching between different systems was a goal of cvssync from the beginning.

>> Being able to track a svn repository and (later) commit to it is
>> sufficient to my needs. (same goes for git)
> (and cvs) yes, entirely.  At least, it will be well after this works
> perfectly that I'll think about anything more to want :)

Working perfectly is a high standard given things like propagates,
directory renames and such. ;-)


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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