river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Parry <david.pa...@suranyami.com>
Subject Re: Branching strategy (Was: svn commit: r601098 - /incubator/river/trunk/jtsk/doc/release-notes/index.html)
Date Fri, 21 Dec 2007 22:58:19 GMT
On 22/12/2007, at 9:43 AM, Craig L Russell wrote:
> It sounds like the main issue is what to call the maintenance and  
> the skunkworks parts of the code tree, having agreed on trunk and  
> tags. Jukka likes branches for maintenance and skunk for skunkworks.  
> Mark likes maintenence for maintenance and branches for skunkworks.

There is another reason for keeping with the naming convention of  
"branches": Most of the Subversion tools do smart url management when  
dealing with branches, whereby there is an assumption that the root  
directory of a project looks something like this:

/trunk
/branches
/tags

Look in Subversive for Eclipse, for instance. When creating a new  
repository, it assumes that these are the names of things, and when  
you issue branch and merge commands, it looks in the /branches  
directory for the branches to manipulate. Using another naming  
convention for the top level will simply make more work when doing  
this kind of work because you'll manually have to find the branches.

These suggestions for other naming conventions seem to be from people  
that haven't been regularly using Subversion. Can I suggest that it  
might be a good idea to initially defer to the conventions, until such  
time as everyone is comfortable enough with using Subversion (say in 6  
months time or so)? Learning a new version control system is always  
painful, so why make it more difficult by doing things the hard way?

Also, given that you can put whatever directory structures you like  
under branches and tags (e.g. maintenence, whatever), that it's hardly  
limiting.



Mime
View raw message