[Gdal-dev] RFC 2: Migration to OSGeo Subversion Repository

[Daniel Morissette]

Frank Warmerdam wrote:
> 
> Apparently you just copy the whole source tree from the "trunk" directory
> into an appropriately named directory under the "branch" directory.  No
> special commandline options or anything like that.  Apparently SVN
> maintains these copies efficiently (not copying actual data, just 
> pointers).
> 
> I haven't lived in that regime yet, but hopefully it will be straight
> forward.
> 
> CVS branches aren't really *all* that bad, and I've managed to handle
> work with them in mapserver.  But it took me years!
> 

I read a bit about SVN's branching methodology at 
http://svnbook.red-bean.com/en/1.1/ch04s02.html and my first reaction 
was "what a mess!". I mean it creates quite a mess over time if you 
expose all branches as new directories in the repository that are all 
checked out by default if you checkout the root of a project's repository.

My fear was confirmed by the following paragraph at the end of that page:
"Unlike many other version control systems, Subversion's branches exist 
as normal filesystem directories in the repository, not in an extra 
dimension. These directories just happen to carry some extra historical 
information."

I think I prefer CVS' way of handling branches as an extra dimension, 
but since everybody is going wild about SVN being better than CVS these 
days I guess I'll have to get used to it.



>> In the RFC you wrote:
>> "All source files in SVN will have the svn:keywords property set to 
>> "Id" by Frank after they are created."
>>
>> Does this mean that SVN doesn't use the "$Id: $" keyword by default 
>> and that any new files will need to have this flag set to it after 
>> it's been added to the repository?
> 
> 
> That is correct.  You need to mark files specially to tell them to
> expand special variables.  Bob Bray wrote up a bit of info on how to
> have SVN clients do some of this automatically for new files.
> 
>   https://mapguide.osgeo.org/subversionconfig.html
> 
> I imagine most of this would apply to us as well.
> 

Ouch! Are there not ways to control these defaults on the server side? 
It sounds a bit clunky to me to require that users/developers edit their 
default SVN config in order to get things working as expected.

If I understood correctly, if I don't edit my local SVN config and then 
create/commit a new file to the GDAL repository, then the auto props may 
not be set on it, and the "$Id: $" (for instance) would not be handled 
properly, is that right? If yes then I'm very disappointed.

With respect to the "$Id: $", should we not modify our std headers to 
use whatever is the SVN equivalent instead of relying on all developers 
maintaining their config locally to contain whatever auto prop the 
project requires for $Id: $ to work? I checkout CVS copies of projects 
to new systems all the time and I don't want to have to copy/edit my SVN 
config everytime I go to a new system.

Hopefully I misunderstood something and it's not really that bad.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/