[Top][All Lists]

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

Re: Proposal: Subversion Migration

From: Andrew Ruder
Subject: Re: Proposal: Subversion Migration
Date: Sun, 23 Oct 2005 14:37:02 -0500
User-agent: Mutt/1.5.9i

On Sun, Oct 23, 2005 at 06:50:31AM -0700, Gregory John Casamento wrote:
> > > >/libs/base/{trunk,tags,branches}
> > > >/libs/gui/{trunk,tags,branches}
> > > >/libs/Renaissance/{trunk,tags,branches}
> > > >/apps/Gorm/{trunk,tags,branches}
> > > >/apps/gworkspace/{trunk,tags,branches}
> > > >
> > > >and so on.
> > > >
> > > >We could then have something like:
> > > >
> > > >/modules/dev-apps
> > > >/modules/core
> > > >/modules/dev-libs
> > > >
> > > >
> > > Sure. but I am not very familiar with svn.
> > 
> > Maybe someone who is familiar with svn can give a basic OK to this
> > layout.  Greg?
> I believe, that until we come up with a plan to modularize things further, we
> should leave the directory layout as it is.   The way I see it we have two
> choices:
> 1) Take the CVS repository whole-cloth into the SVN repo and make any changes
> incrementally from there.
> 2) Take the burden of a redesign/relayout now and put it into SVN in some new
> layout.

The relayout during the conversion is very simple.  I was only
suggesting it because sometimes it is easier to follow the history when
things have not been rearranged :)

Plus, having a trunk/branches/tags per project would be much cleaner
than having a single trunk/branches/tags for the entire project.  (i.e.
if we have a single tags directory, we'll be making tags like 


whereas if we lay it out properly, we'll just have


Likewise we wouldn't have every projects tags and branches cluttering up
every other projects tags and branches hierarchy.  The cvs2svn utility
also does a decent job of figuring out which tags and branches applied
to which subprojects.  i.e.

shows only the tags made on GORM afaict.

We can of course, reorganize in the tree and move around all the tags
and branches to the appropriate places, but that may actually be more
difficult :)

> This would be easier to verify if we simply did a wholesale copy from one repo
> to another.  Unless you're referring to *all* of the metadata (history, etc)
> for each file.  That's somewhat more difficult. :)

Good point.  Either way, a simple shell script or perl script can do the
grunt work.

Andrew Ruder

reply via email to

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