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

[Bill Binko]

Daniel,

I'm not a Subversion expert (I've used it as a client only).  However, I
think this can be solved using a Hook Script ( see
http://subversion.tigris.org/tools_contrib.html#hook_scripts )

>From what I've seen, svn calls hooks pre- and post-commit, and they
provide both a command-line toolset and language bindings (primarily
Perl & Python) to manipulate the SVN system.

That means that you could write a pre-commit script that added the
properties if the file was of a certain type (.c, etc.).  Alternatively,
you could just reject the addition and give instructions on how to setup
the client to set the properties.  That script already exists and could
just be modified as needed (see
http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl )

I hope this helps.  I'm sure given the Python expertise in this audience
(myself excluded), there's a solution here.

Bill

On Fri, 2006-05-05 at 08:27 -0400, Daniel Morissette wrote:
> 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
-- 
Bill Binko <bill at binko.net>