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

[Daniel Carosone]

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

Yeah. As well as the modules and rename benefits, consider a bunch of
files and a subdirectory I've added in monotone but not yet synced to
cvs.  They'd grow these attr's when the 'cvs add' and commit was done.

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

Yeah, I agree..  I find it's useful to be sure about what you don't
want to do as well.

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

They're odd.  As in monotone, any commit can be a child of any other,
so you get a forking ancestry tree (SVN ids revisions sequentially as
they arrive at the central server, and the numbers mean nothing about
the graph).

Then they use the property that you can checkout (and commit) in
subtrees of the overall repository, as in CVS, to establish some
naming conventions.  The top few dirs in a repository aren't used for
the actual project, but for making branches.  Typically, there's a
trunk/ and a branches/ dir, and a dir for each branch under there.

Most people check out and work with one of those subdirectories,
rather than the repository root, so they get what looks like
conventional branches. Ancestry lines tend to match commits isolated
in each of these directories.

To make the files in those directories be connected to their history
before the branch diverged, SVN has a clone or copy routine.  To make
a new branch, you copy the contents+history from the trunk subdir (or
another branch subdir) to a new branch subdir.  To accurately
represent SVN in monotone, we're going to need such an operation too
one day - and there are other uses for it regardless.

Note that this means you can branch a file at a time, and that there's
no enforcement of these conventions, even if they're normally well
followed except by confused newbies. I made a horrid mess the one and
only time I tried. :-)

My question was whether we want to assume SVN users have been
following these conventions, and import subdirs onto separate monotone
branches, or just import the whole tree as a big blob.  Both have
issues, especially if people haven't followed the conventions.

That's where my knowledge ends, I've never really used SVN for
development. In particular, I don't know much about how merging of
those revisions works, but I don't think they generate graph merges,
only file merges (much like CVS).  Someone else can fill in more
details here if needed.

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

Oh, awesome!

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

When making wishes, you might as well be ambitious :-)

--
Dan.

pgp2WjPmGO0Ef.pgp
Description: PGP signature