COmanage Developers List

[Scott Koranda <>]

> With Directory, we're going to have to do something about the source
> tree. In short, the problem is the tree is currently structured as
> 
>  /svn/gears/{tags,trunk,vendor}
> 
> In this context, gears=registry, so we need to do something for directory.
> 
> The simplest option is for me to request
> 
>  /svn/directory/
> 
> At the same time, I could ask /svn/gears be migrated to
> /svn/registry. Doing so will require a code freeze, since from your
> point of view you'll be checking out a new repository to work
> against. During a code freeze, any changes you make to your working
> copy will need to be re-applied to the new working copy that gets
> created.
> 
> Alternately (and reducing the need to request changes from TSG going
> forward), I could request
> 
>  /svn/comanage
> 
> then move gears to /svn/comanage/registry, and create
> /svn/comanage/directory. Again, a code freeze will be required.
> 
> What this boils down to, I think, are three options:
> 
> (1) Separate repository per product
>     (/svn/registry, /svn/directory)
> (2) One repository with one trunk per product
>     (/svn/comanage/registry, /svn/comanage/directory)
> (3) One repository with one trunk
>     (/svn/comanage/trunk/registry, /svn/comanage/trunk/directory)
> 
> In options #2 and #3, revision numbers are "shared" across products.
> This would allow a single commit to introduce changes to both
> products, which might be useful under limited circumstances.
> 
> For reasons previously explained, I don't want to factor a git
> migration in here, but whatever we decide should be compatible with
> a future git migration.
> 
> I'm leaning towards (2) with a code freeze after 0.3 is tagged.
> 
> Comments?
> 

I defer to you and am happy with any of those solutions.

Thanks,

Scott