[Gdal-dev] RFC 3: GDAL Commiter Guildlines
dmorissette at mapgears.com
Thu Nov 2 08:52:22 EST 2006
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
>> 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
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:
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.
More information about the Gdal-dev