[Gdal-dev] RFC 3: GDAL Commiter Guildlines

[Daniel Morissette]

Marek Brudka wrote:
> 
>> That's assuming I understood Mateusz' explanation right and branching 
>> indeed means duplicating the whole directory tree on the server.
> It's only a logical copy. Files and directories are physically copied on 
> new commits only.

Good to hear. That makes me feel a bit better.


>>
>> Is it really common practive with SVN-based projects to create private 
>> branches and merge like this? 
> Yes, it is. Obviosly not for a single line patches, but for more serious 
> works.
>> Is this not abusing the features of the source code management system? 
> Which features and how?
>> Is there a way to physically delete a private branch from the SVN server
> AFAIK no.
>> and remove any trace from it in order to keep the repository clean?
> What for? What does it mean clean?
> 

By clean I mean that I would like to see only branches and tags related 
to releases of the software in the repository. In a few year from now I 
won't be interested in seeing dozens of private branches all over the 
place... that's the mess I am referring to. Maybe your company's 
repository doesn't look too bad after 2 years, perhaps that's because 
there are only a few developers and release branches are not that 
frequent? We are talking about a project with 20+ developers, with a 
couple of significant releases (release means branch) per year, and that 
is going to be around for several years. The history in the current GDAL 
repository starts in 1998, that's 8 years ago ... add another 10 years 
to that and imagine what a repository would look like with 18 years of 
private branches.

I realize that private branches seem to be a new trend, but personally I 
find this is not proper use of the source code repository.

In my ideal world, the CVS/SVN repository would contain only release 
tags and branches, named in a systematic way so that we can easily track 
them, and exceptionally we may create dev branches for major feature 
development outside of the main trunk but that should be the exception, 
not the rule.

For instance, in the case of the MapServer project's CVS repository, all 
development always happens in the trunk and we use "branch-x-y" for 
stable release branches and "rel-x-y-z" to tag releases. This gives the 
following tag/branches history for the last 3 years for map.h which is 
probably the most frequently modified file in the whole project:

         rel-4-10-0: 1.469
         branch-4-10: 1.469.0.2
         rel-4-10-0-rc1: 1.468
         rel-4-10-0-beta3: 1.465
         rel-4-10-0-beta2: 1.462
         rel-4-10-0-beta1: 1.459
         rel-4-8-4: 1.437.2.9
         rel-4-8-3: 1.437.2.8
         rel-4-8-2: 1.437.2.7
         rel-4-8-1: 1.437.2.5
         rel-4-8-0: 1.437.2.4
         rel-4-8-0-rc3: 1.437.2.2
         branch-4-8: 1.437.0.2
         rel-4-8-0-rc2: 1.437
         rel-4-8-0-rc1: 1.436
         rel-4-8-0-beta3: 1.435
         rel-4-6-2: 1.416.2.2
         rel-4-8-0-beta2: 1.432
         rel-4-8-0-beta1: 1.430
         rel-4-6-1: 1.416.2.1
         branch-4-6: 1.416.0.2
         rel-4-6-0: 1.416
         rel-4-6-0-rc1: 1.414
         rel-4-6-0-beta3: 1.413
         rel-4-6-0-beta2: 1.407
         rel-4-6-0-beta1: 1.405
         rel-4-4-2: 1.382.2.2
         rel-4-4-1: 1.382.2.1
         branch-4-4: 1.382.0.2
         rel-4-4-0: 1.382
         rel-4-4-0-beta3: 1.381
         rel-4-4-0-beta2: 1.365
         rel-4-4-0-beta1: 1.361
         rel-4-2-5: 1.302.2.18
         rel-4-2-4: 1.302.2.17
         rel-4-2-3: 1.302.2.11
         rel-4-2-2: 1.302.2.10
         rel-4-2-1: 1.302.2.8
         rel-4-2-0: 1.302.2.7
         rel-4-2-0-beta3: 1.302.2.6
         rel-4-2-0-beta2: 1.302.2.1
         branch-4-2: 1.302.0.2
         rel-4-0-2: 1.255.2.2
         rel-3-6-7: 1.150.2.17
         rel-4-0-1: 1.255.2.1
         rel-4-0-0: 1.255
         branch-4-0: 1.255.0.2

This is what I call clean... add 3 years of private branches for 20+ 
developers to that and you get what I'd call a mess.

My 0.02$,

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