Re: cvssync (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?))

[Daniel Carosone]

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 the parent directory.  

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).

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.

> 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 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 :)

> > To see if I understand you right: I know it is possible to have a svn
> > workspace that is a mix of different versions.  You want to make it
> > possible to import such mixed versions into monotone, and do
> > svn_push/svn_pull type operations with such mixed versions?
> 
> I did not know about such monstrosities and did not plan to support them
> (initially at least).

I think you can have a workspace like that (much like running update
in a subdir with CVS) but I don't think it makes any kind of sense to
have a revision like that.  If you commit from such a workspace it's
like a restricted commit in monotone, you'll create a new revision,
even if your workspace still doesn't exactly correspond to a revision.

So I think this isn't an issue for imports and syncs that only deal
with committed revisions rather than workspaces from the other tool.

> 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 :)

--
Dan.

pgpAZQStMQCZ7.pgp
Description: PGP signature