[development] CVS branch work best practices?

Bèr Kessels ber at webschuur.com
Fri Feb 2 20:12:52 UTC 2007


I'd love too keep this whole discussion on track :) , so lets summarize: 

* Dries suggest we either go for a), or b). A) being 'you wait for 
improvements until there is a new core release'. B) being, you keep HEAD in 
track with core HEAD. 

* Many people suggest that there are a lot of ways to tackle module 
maintainance. To me this proves that my orgininal request -to find a 
good/best practice- is far from the trivial question I hoped it to be. There 
*is* no best practice, there are at least four, depending on your needs and 
skills, and probably more.

* People mentioned in several occasions that CVS is difficult stuff. I think 
this is a known fact for many, but it is a very important fact. Dries talked 
about 'keeping code accessible for new developers' often. Well, Drupal code 
may be that, I think the 'required' CVS skills to actually use/contribute the 
work defeat a lot of that accessible code. Just a thing to remember, IMO. 

* While choises are good, I think my original question: what is the way to 
maintain your modules without spending loads of time on CVS matters (as in: 
spend your time coding, not in CVS burocracy), has only been answered by ajk. 
Let me stress that this is not the only one. Its just the best (IMO) if you 
want to Spend Less CVS Time, and more code-quality time. This 'best practice' 
went into the handbook already. Thanks ;)

I think the discussion in this thread proves above all that CVS is, eehm, not 
perfect. But to quote Boris: it just sucks less. 

Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20070202/d51cad55/attachment.pgp 

More information about the development mailing list