[support] CVS/SVN best practices

Earnie Boyd earnie at users.sourceforge.net
Sun Jul 8 04:27:16 UTC 2007


----- Message from georg.rehfeld at gmx.de ---------
    Date: Sun, 08 Jul 2007 05:24:15 +0200
    From: Georg Rehfeld <georg.rehfeld at gmx.de>
Reply-To: support at drupal.org
Subject: [support] CVS/SVN best practices
      To: support at drupal.org


> Hi all,
>
> I'm a Drupal newby, having read this list for 7 days now, before
> attempting to post (but didn't search the archives thoroughly).
>
> For a new Drupal site I use a Subversion (SVN) Repository, to be able
> to track/revert changes to every modification I/we do to the site, e.g.
> theme adaptions.
>
> My current problem is: in many Drupal files (core and otherwise) there
> is that special CVS/SVN string "$Id ... $".
>
> When I now check in the original Drupal sources into _my_ SVN repository
> all these $Id$ strings get replaced with my/our commit info.
>
> In the first place this would be an (unwanted) fake: I/we ain't authors/
> responsible for these files at all!
>
> And, when synchronizing the local working copy with the life web server,
> all these files show up as modified! Which is very annoying, because
> _real_ changes are hidden amoung these fakes!
>
> I would like to read, what's _your_ best practice to avoid that.
>

$Id $ is an RCS tag; see http://www.jnrowe.ukfsn.org/articles/rcs.html 
for a good explaination.

$Id $ isn't then only RCS tag affected by your incidental checkin.  To 
avoid your import changing the values -ko can be used by either CVS or 
SVN to maintain the current value of the tags.

For Drupal suggestions as to best practice look at 
http://www.google.com/search?num=100&hl=en&safe=active&q=CVS+best+practice+site%3Adrupal.org&btnG=Search for many pages of 
discussion.

Earnie


More information about the support mailing list