[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Our abuse of CVS tagging

From: Craft, Steven <SCraft_at_t-tales.com>
Date: 2007-11-09 19:43:23 CET

Hi,
 
We are in the process of doing a trial run of SVN so we can move away from
CVS, however due to our abuse of the CVS tagging system we are currently not
entirely sure how to proceed. Please let me explain:
 
We have a team that works on an 'API' and several other teams that use the
'API' to make their own 'project(s)', so in CVS there is a structure
something like:
 
.\api
.\project1
.\project2
.\project3
 
i) The team working on the 'API' commit all their changes into the 'HEAD' of
the 'API'.
ii) A long time ago we made a 'TAG' of the 'API's head branch and called it
'SAFE'. The project teams then started to use the 'SAFE' version by always
checking that out (the project teams never modify the 'API'). There is
actually more than one 'TAG' version as different project teams deem
different code 'SAFE', this however isn't of direct importance.
iii) One person per project (usually the lead programmer) is in charge of
keeping (reasonably) up to date with the latest 'API' changes, to do this he
will periodically checkout the 'HEAD' version of the 'API', ensure it works
correctly with his project, and (assuming it works) move the 'SAFE' tag (to
'HEAD').
iv) As deadlines approach, or particular builds are required the project
teams no longer wish to update the entire 'API' periodically and instead
will keep using the 'SAFE' version, however, they often find bugs, or decide
that they need certain features that are in the 'HEAD' branch - so the lead
programmer updates the files needed (for bug fixes/new features), checks
everything works correctly and then moves the tag for those files (so they
are now in the 'SAFE' tag for everyone else in the project team to use).
v) When the project gets very near to completion we completely branch off
the API for at this stage we do want to be making any changes to the API
(except crucial bug fixes). When the crucial bug fixes are made they are
made to the branch (and only duplicated in 'HEAD' if they address an issues
that is needed on other projects).
vi) Once the project is over, any relevant changes from the project's API
branch are merged back in to the 'HEAD' (assuming they haven't already been
made to 'HEAD').
 
I haven't found a way to work in the same way with SVN, I have spent a fair
amount of time searching the internet and this mailing list to see if other
people are using this approach but haven't got any concrete answers yet. We
do not mind changing the way in which we work, the main thing we want to be
able to do is let the project teams work with snapshots of the API and have
them choose when they wish to update their snapshot - it is not acceptable
for them to have to update the entire API in one go, they must be able to
update individual files/subfolders independently. One way I have found that
sort of works (in SVN) is to have a TAG of the API, then if the project
teams want to update certain files they can select the files and merge them
against the HEAD of the TRUNK, they can then commit the resultant files into
their TAG (okay you aren't really meant to commit to a tag). This then
leaves them in the same situation as they were in with CVS which is good -
however it does mean when I check the log/history for files I see loads of
comments that say something along the lines of "Moved the SAFE tag", which
isn't particularly useful.
 
Any pointers as to how to go about tackling this would be gratefully
received,
 
 
Steven Craft
 
 
                                                
 
 
  <http://www.ttgames.com/>
 
Received on Mon Nov 12 23:57:37 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.