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

[Marek Brudka]

Bill Binko napisał(a):

>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.).  
>
The major SVN rule in subversion is: "*Server does not modify the 
contents*".
After a switch from cvs to svn 6 months ago we got stuck with this 
several times.

 From svn redbook:
/"Do not attempt to modify the transaction using hook scripts. A common 
example of this would be to automatically set properties such as 
svn:eol-style or svn:mime-type during the commit. While this might seem 
like a good idea, it causes problems. The main problem is that the 
client does not know about the change made by the hook script, and there 
is no way to inform the client that it is out-of-date. This 
inconsistency can lead to surprising and unexpected behavior.

Instead of attempting to modify the transaction, it is much better to 
check the transaction in the pre-commit hook and reject the commit if it 
does not meet the desired requirements."
/

>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 )
>  
>
>>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."
>>    
>>
Nothing to warry about :-). The branching is cool in svn :-)

>>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.
>>    
>>
My experience with svn is that it promises more than it really provides. 
IMHO the major
benefit of svn are the atomicity of commits as well as branching and 
tagging scheme. Moving
and copying of files and directories works in general as expected, but 
some users had several
(newbie) problem with this.

The major drawback of svn when compared to cvs is the lack of third 
party OS software eg. the only
way to publish source in WWW is (was?) webcvs which is not very well for 
svn.

My conclusions on switching from cvs to svn in my company are:
 - we will rather not get back to cvs,
 - if we knew as much about svn as today, we should have reconsider our 
decision more .. consciously,
   as the benefits sometimes seem to be not worth the price of transition.

Regards
Marek