PSC: Interesting Conundrum

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

PSC: Interesting Conundrum

Robert Bray-2
It seems we have an interesting issue that we need to make a decision on. Under CollabNet we had multiple SVN repositories, one for the core API and one per provider. At the same time we had a single bug database for all of FDO.

In the new infrastructure we will be using Trac for our defect/enhancement tool. However according to Shawn a single Trac instance can reference only one SVN repository. This is a known Trac limitation that there is no known workaround for at the moment. So we have a couple of choices:
  1. Merge the SVN repositories into one. This can be done without losing any history, and from what I read it would be possible to either have branches on a per provider basis (like we do now) or a single branch across all of FDO. That later is more work but might be cleaner long term if we take this approach.
  2. Have multiple Trac instances, one for FDO Core and one for each Provider.
>From a long term management perspective I am leaning toward #1. The original reason for splitting the repositories was to allow for the list of committers to vary from provider to provider. Outside CollabNet this can be achieved with a single repository if that is still a requirement, however again from a management perspective it might be easier to just manage a single committer list for all of FDO.

Thoughts, opinions, and recommendations please...

Bob


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Mateusz Loskot
Robert Bray wrote:
> So we have a couple of choices:
>
>    1. Merge the SVN repositories into one. This can be done without
>       losing any history, and from what I read it would be possible to
>       either have branches on a per provider basis (like we do now) or a
>       single branch across all of FDO. That later is more work but might
>       be cleaner long term if we take this approach.

I second this option.

Also, I'd suggest to consider if it would be reasonable to flatten the
directories layout:

trunk\fdocore
trunk\fdordbms
trunk\fdoshp
...

instead of keeping Providers deep in the structure, under:
trunk\fdocore\Providers\...
or
trunk\fdocore
trunk\Providers\...

Personally, I keep FDO stuff following the proposed structure and
it works for me better than checkouting provider into the fdocore
tree, to Providers directory.

Also, I can confirm branching will be as easy as it's now.
Simply, in SVN branches or tags can be created for any
subtree of the repo.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC: Interesting Conundrum

Robert Fortin
In reply to this post by Robert Bray-2
All in favor of option 1. Providers are always targeting a specific
version of FDO so it make sence that they are generally branched with
FDO.  Splitting the reporitories has resulted in additional work when
creating branch plus issues around common component used across
providers.

RF

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Mateusz
Loskot
Sent: Tuesday, January 16, 2007 2:07 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC: Interesting Conundrum

Robert Bray wrote:
> So we have a couple of choices:
>
>    1. Merge the SVN repositories into one. This can be done without
>       losing any history, and from what I read it would be possible to
>       either have branches on a per provider basis (like we do now) or
a
>       single branch across all of FDO. That later is more work but
might
>       be cleaner long term if we take this approach.

I second this option.

Also, I'd suggest to consider if it would be reasonable to flatten the
directories layout:

trunk\fdocore
trunk\fdordbms
trunk\fdoshp
...

instead of keeping Providers deep in the structure, under:
trunk\fdocore\Providers\...
or
trunk\fdocore
trunk\Providers\...

Personally, I keep FDO stuff following the proposed structure and it
works for me better than checkouting provider into the fdocore tree, to
Providers directory.

Also, I can confirm branching will be as easy as it's now.
Simply, in SVN branches or tags can be created for any subtree of the
repo.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Frank Warmerdam
Robert Fortin wrote:
> All in favor of option 1. Providers are always targeting a specific
> version of FDO so it make sence that they are generally branched with
> FDO.  Splitting the reporitories has resulted in additional work when
> creating branch plus issues around common component used across
> providers.

Folks,

I am also in favor of merging the repositories.  Generally speaking I don't
think mechanical means are the right way to restrict people to operating on
limited parts of the code.  If we don't trust someone enough to obey
procedures on what parts of the code base they can modify, then we shouldn't
be giving them commit access.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Paul Ramsey-2
I'm with Frank. Geotools and udig share the same repositories, we have
different people with commit privs, and we have *never* had a problem
with people committing where they shouldn't.  Even though SVN allows us
to lock up the different trees with ACLs, we have never bothered.

Paul

Frank Warmerdam wrote:

> Robert Fortin wrote:
>> All in favor of option 1. Providers are always targeting a specific
>> version of FDO so it make sence that they are generally branched with
>> FDO.  Splitting the reporitories has resulted in additional work when
>> creating branch plus issues around common component used across
>> providers.
>
> Folks,
>
> I am also in favor of merging the repositories.  Generally speaking I don't
> think mechanical means are the right way to restrict people to operating on
> limited parts of the code.  If we don't trust someone enough to obey
> procedures on what parts of the code base they can modify, then we
> shouldn't
> be giving them commit access.
>
> Best regards,

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC: Interesting Conundrum

Dan Stoica
In reply to this post by Robert Bray-2
Yet another reason to favour option 1:  in many cases a certain fix is
made in code shared by several providers (e.g. FdoCommon). That is, it
affects other providers as well.

Dan.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Paul Ramsey
Sent: Tuesday, January 16, 2007 2:39 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC: Interesting Conundrum

I'm with Frank. Geotools and udig share the same repositories, we have
different people with commit privs, and we have *never* had a problem
with people committing where they shouldn't.  Even though SVN allows us
to lock up the different trees with ACLs, we have never bothered.

Paul

Frank Warmerdam wrote:

> Robert Fortin wrote:
>> All in favor of option 1. Providers are always targeting a specific
>> version of FDO so it make sence that they are generally branched with
>> FDO.  Splitting the reporitories has resulted in additional work when
>> creating branch plus issues around common component used across
>> providers.
>
> Folks,
>
> I am also in favor of merging the repositories.  Generally speaking I
don't
> think mechanical means are the right way to restrict people to
operating on
> limited parts of the code.  If we don't trust someone enough to obey
> procedures on what parts of the code base they can modify, then we
> shouldn't
> be giving them commit access.
>
> Best regards,

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Robert Bray-2
In reply to this post by Frank Warmerdam
Ok, so the next step is figuring out what the repository should look
like. Trying to avoid as much pain as possible I'd like to propose
something like:

/fdo    - Repository
 /trunk
  /fdodev
   /fdo
   /thirdparty
   /utilities
   /providers
    /sdf
    /shp
    /...
 /branches
  /3.2.x
   /fdodev
    ...
 
With some creative manipulation of the svn dumps and the --parent-dir
option of the svnadmin load command I think we can restructure things
without loss of history or anything else. The build scripts will need a
fair bit of updating however.

Other ideas or suggestions welcome of course.

Bob
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Mateusz Loskot
Robert Bray wrote:

> Ok, so the next step is figuring out what the repository should look
> like. Trying to avoid as much pain as possible I'd like to propose
> something like:
>
> /fdo    - Repository
> /trunk
>  /fdodev
>   /fdo
>   /thirdparty
>   /utilities
>   /providers
>    /sdf
>    /shp
>    /...
> /branches
>  /3.2.x
>   /fdodev
>    ...
>
> Other ideas or suggestions welcome of course.


What about a little modification?

- trunk
-- fdo
--- core
--- utilities
--- thirdparty
--- providers
---- sdf
---- shp
---- oracle
- branches
- tags


So, there is the 'fdo' module that holds everything what makes FDO.
Next, if reasonable, we could add 'fdotools' module this way:

- trunk
-- fdo
-- fdotools


Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC: Interesting Conundrum

Greg Boone
In reply to this post by Robert Bray-2
Why do we you recommend the /fdodev parent directory?

Why not....

/fdo    - Repository
 /trunk
   /fdo
   /thirdparty
   /utilities
   /providers
    /sdf
    /shp
    /...

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Robert Bray
Sent: Tuesday, January 16, 2007 3:11 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC: Interesting Conundrum

Ok, so the next step is figuring out what the repository should look
like. Trying to avoid as much pain as possible I'd like to propose
something like:

/fdo    - Repository
 /trunk
  /fdodev
   /fdo
   /thirdparty
   /utilities
   /providers
    /sdf
    /shp
    /...
 /branches
  /3.2.x
   /fdodev
    ...
 
With some creative manipulation of the svn dumps and the --parent-dir
option of the svnadmin load command I think we can restructure things
without loss of history or anything else. The build scripts will need a
fair bit of updating however.

Other ideas or suggestions welcome of course.

Bob
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC: Interesting Conundrum

Greg Boone
In reply to this post by Robert Bray-2
Why not add tools as a equal to core and utilities under fdo (see below)
and have a single make build process that builds everything? Making it
an equal of fdo only complicates the build and makes things a little
harder to find as you browse the repository.

- trunk
-- fdo
--- tools
--- core
--- utilities
--- thirdparty
--- providers
---- sdf
---- shp
---- oracle
- branches
- tags

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Mateusz
Loskot
Sent: Tuesday, January 16, 2007 3:23 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC: Interesting Conundrum

Robert Bray wrote:

> Ok, so the next step is figuring out what the repository should look
> like. Trying to avoid as much pain as possible I'd like to propose
> something like:
>
> /fdo    - Repository
> /trunk
>  /fdodev
>   /fdo
>   /thirdparty
>   /utilities
>   /providers
>    /sdf
>    /shp
>    /...
> /branches
>  /3.2.x
>   /fdodev
>    ...
>
> Other ideas or suggestions welcome of course.


What about a little modification?

- trunk
-- fdo
--- core
--- utilities
--- thirdparty
--- providers
---- sdf
---- shp
---- oracle
- branches
- tags


So, there is the 'fdo' module that holds everything what makes FDO.
Next, if reasonable, we could add 'fdotools' module this way:

- trunk
-- fdo
-- fdotools


Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Paul Ramsey-2
In reply to this post by Mateusz Loskot
Unless fdotools is going to be released in the same versioning scheme as
fdo, I would not recommend this, I would recommend two trees in the same
repository.

/fdo/trunk/
/fdo/tags
/fdo/branches

/fdotools/trunk
/fdotools/tags
/fdotools/branches

Mateusz Loskot wrote:

> So, there is the 'fdo' module that holds everything what makes FDO.
> Next, if reasonable, we could add 'fdotools' module this way:
>
> - trunk
> -- fdo
> -- fdotools


--

   Paul Ramsey
   Refractions Research
   http://www.refractions.net
   [hidden email]
   Phone: 250-383-3022
   Cell: 250-885-0632
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Robert Bray-2
In reply to this post by Greg Boone
You need a single root for branch operations. Otherwise you will have to
branch each of those folders or have /branches/3.2.x/trunk which is
kinda weird.

Bob

Greg Boone wrote:

> Why do we you recommend the /fdodev parent directory?
>
> Why not....
>
> /fdo    - Repository
>  /trunk
>    /fdo
>    /thirdparty
>    /utilities
>    /providers
>     /sdf
>     /shp
>     /...
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Robert Bray
> Sent: Tuesday, January 16, 2007 3:11 PM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] PSC: Interesting Conundrum
>
> Ok, so the next step is figuring out what the repository should look
> like. Trying to avoid as much pain as possible I'd like to propose
> something like:
>
> /fdo    - Repository
>  /trunk
>   /fdodev
>    /fdo
>    /thirdparty
>    /utilities
>    /providers
>     /sdf
>     /shp
>     /...
>  /branches
>   /3.2.x
>    /fdodev
>     ...
>  
> With some creative manipulation of the svn dumps and the --parent-dir
> option of the svnadmin load command I think we can restructure things
> without loss of history or anything else. The build scripts will need a
> fair bit of updating however.
>
> Other ideas or suggestions welcome of course.
>
> Bob
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>  

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC: Interesting Conundrum

Greg Boone
In reply to this post by Robert Bray-2
By including tools under fdo we force the tools to remain in sync and
use the same versioning scheme. I think this would make our lives a lot
less complicated. Having fdotools outside of fdo only introduces
complications regarding which version of fdo they apply to.

Greg

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Paul Ramsey
Sent: Tuesday, January 16, 2007 4:06 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC: Interesting Conundrum

Unless fdotools is going to be released in the same versioning scheme as

fdo, I would not recommend this, I would recommend two trees in the same

repository.

/fdo/trunk/
/fdo/tags
/fdo/branches

/fdotools/trunk
/fdotools/tags
/fdotools/branches

Mateusz Loskot wrote:

> So, there is the 'fdo' module that holds everything what makes FDO.
> Next, if reasonable, we could add 'fdotools' module this way:
>
> - trunk
> -- fdo
> -- fdotools


--

   Paul Ramsey
   Refractions Research
   http://www.refractions.net
   [hidden email]
   Phone: 250-383-3022
   Cell: 250-885-0632
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

RE: PSC: Interesting Conundrum

Greg Boone
In reply to this post by Robert Bray-2
I see....

Then I propose that we have the following...

/fdo    - Repository
 /trunk
  /fdodev
   /core
   /tools
   /thirdparty
   /utilities
   /providers
     /sdf
     /shp
     /...
 /branches
  /3.2.x
   /fdodev


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Robert Bray
Sent: Tuesday, January 16, 2007 4:05 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC: Interesting Conundrum

You need a single root for branch operations. Otherwise you will have to

branch each of those folders or have /branches/3.2.x/trunk which is
kinda weird.

Bob

Greg Boone wrote:

> Why do we you recommend the /fdodev parent directory?
>
> Why not....
>
> /fdo    - Repository
>  /trunk
>    /fdo
>    /thirdparty
>    /utilities
>    /providers
>     /sdf
>     /shp
>     /...
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Robert
Bray

> Sent: Tuesday, January 16, 2007 3:11 PM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] PSC: Interesting Conundrum
>
> Ok, so the next step is figuring out what the repository should look
> like. Trying to avoid as much pain as possible I'd like to propose
> something like:
>
> /fdo    - Repository
>  /trunk
>   /fdodev
>    /fdo
>    /thirdparty
>    /utilities
>    /providers
>     /sdf
>     /shp
>     /...
>  /branches
>   /3.2.x
>    /fdodev
>     ...
>  
> With some creative manipulation of the svn dumps and the --parent-dir
> option of the svnadmin load command I think we can restructure things
> without loss of history or anything else. The build scripts will need
a

> fair bit of updating however.
>
> Other ideas or suggestions welcome of course.
>
> Bob
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>  

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Robert Bray-2
Greg,

This makes sense to me, but FYI it will affect the build scripts in the branches. I am going to start another thread to bring this to PSC vote.

Thanks all,
Bob

Greg Boone wrote:
I see....

Then I propose that we have the following...

/fdo    - Repository
 /trunk
  /fdodev
   /core
   /tools
   /thirdparty
   /utilities
   /providers
     /sdf
     /shp
     /...
 /branches
  /3.2.x
   /fdodev


-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Robert Bray
Sent: Tuesday, January 16, 2007 4:05 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC: Interesting Conundrum

You need a single root for branch operations. Otherwise you will have to

branch each of those folders or have /branches/3.2.x/trunk which is 
kinda weird.

Bob

Greg Boone wrote:
  
Why do we you recommend the /fdodev parent directory?

Why not....

/fdo    - Repository
 /trunk
   /fdo
   /thirdparty
   /utilities
   /providers
    /sdf
    /shp
    /...

-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Robert
    
Bray
  
Sent: Tuesday, January 16, 2007 3:11 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] PSC: Interesting Conundrum

Ok, so the next step is figuring out what the repository should look 
like. Trying to avoid as much pain as possible I'd like to propose 
something like:

/fdo    - Repository
 /trunk
  /fdodev
   /fdo
   /thirdparty
   /utilities
   /providers
    /sdf
    /shp
    /...
 /branches
  /3.2.x
   /fdodev
    ...
 
With some creative manipulation of the svn dumps and the --parent-dir 
option of the svnadmin load command I think we can restructure things 
without loss of history or anything else. The build scripts will need
    
a 
  
fair bit of updating however.

Other ideas or suggestions welcome of course.

Bob
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

  
    

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

  


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Mateusz Loskot
In reply to this post by Paul Ramsey-2
Paul Ramsey wrote:

> Unless fdotools is going to be released in the same versioning scheme as
> fdo, I would not recommend this, I would recommend two trees in the same
> repository.
>
> /fdo/trunk/
> /fdo/tags
> /fdo/branches
>
> /fdotools/trunk
> /fdotools/tags
> /fdotools/branches

You're right, but I'm not sure how fdotools will be released, together
with FDO or not but available on SVN only.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Mateusz Loskot
In reply to this post by Robert Bray-2
Robert Bray wrote:
> You need a single root for branch operations. Otherwise you will have to
> branch each of those folders or have /branches/3.2.x/trunk which is
> kinda weird.

Right, good point.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Mateusz Loskot
In reply to this post by Greg Boone
Greg Boone wrote:
> Why not add tools as a equal to core and utilities under fdo (see below)
> and have a single make build process that builds everything? Making it
> an equal of fdo only complicates the build and makes things a little
> harder to find as you browse the repository.
>
> - trunk
> -- fdo
> --- tools

I like this approach, if you don't consider it as messing the FDO
tree itself.
Also, it would mean that tools are compatible/usable with particular
version of FDO, release (in tag) or the dev stream in trunk,
what Paul has already mentioned.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: PSC: Interesting Conundrum

Mateusz Loskot
In reply to this post by Greg Boone
...but why fdodev instead of fdo ?

Mat


Greg Boone wrote:

> I see....
>
> Then I propose that we have the following...
>
> /fdo    - Repository
>  /trunk
>   /fdodev
>    /core
>    /tools
>    /thirdparty
>    /utilities
>    /providers
>      /sdf
>      /shp
>      /...
>  /branches
>   /3.2.x
>    /fdodev
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Robert Bray
> Sent: Tuesday, January 16, 2007 4:05 PM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] PSC: Interesting Conundrum
>
> You need a single root for branch operations. Otherwise you will have to
>
> branch each of those folders or have /branches/3.2.x/trunk which is
> kinda weird.
>
> Bob
>
> Greg Boone wrote:
>> Why do we you recommend the /fdodev parent directory?
>>
>> Why not....
>>
>> /fdo    - Repository
>>  /trunk
>>    /fdo
>>    /thirdparty
>>    /utilities
>>    /providers
>>     /sdf
>>     /shp
>>     /...
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Robert
> Bray
>> Sent: Tuesday, January 16, 2007 3:11 PM
>> To: FDO Internals Mail List
>> Subject: Re: [fdo-internals] PSC: Interesting Conundrum
>>
>> Ok, so the next step is figuring out what the repository should look
>> like. Trying to avoid as much pain as possible I'd like to propose
>> something like:
>>
>> /fdo    - Repository
>>  /trunk
>>   /fdodev
>>    /fdo
>>    /thirdparty
>>    /utilities
>>    /providers
>>     /sdf
>>     /shp
>>     /...
>>  /branches
>>   /3.2.x
>>    /fdodev
>>     ...
>>  
>> With some creative manipulation of the svn dumps and the --parent-dir
>> option of the svnadmin load command I think we can restructure things
>> without loss of history or anything else. The build scripts will need
> a
>> fair bit of updating however.
>>
>> Other ideas or suggestions welcome of course.
>>
>> Bob


--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals