Strike, Jeff wrote:
> We're currently in the process of upgrading our build and deployment
> process for our Java environment, part of that means upgrading our
> source control. Currently there is no build process in place and there
> is one monolithic exploded deployment that actually has about 10-15
> different applications all using the same context root. (This is a
> mixture of JSP applications and Struts applications) Currently we're
> using a program called AccuRev for version control. When you promote a
> file in AccuRev it goes to the DEV depot. (repository) Once it's there
> someone can review the files and decide to push them to the server.
> After they're tested the files are pushed to the next depot for QA and
> so on. The pushing of files from one repository is a manual process but
> it allows the person responsible for deployment to pick and choose what
> files for which applications get pushed. Since everything is deployed
> as one application this works out good if we have people working on
> different applications at the same time. Starting with this upgrade all
> new projects will be developed outside of the old application as
> individual projects. We still need to maintain those old applications
> until we separate them out into new applications or they reach their end
> of life. I'd like to get rid of AccuRev and replace it with SVN but not
> sure how we can use SVN to decide which files need to go in the build
> and which don't.
>
> Example:
> Dev A is working on App 1 and commits files to SVN
> Dev B & C are working on App 2 and commits files to SVN so they share
> their work.
> These are all in the same repository…how can I set this up so a build
> script (Ant) will know which files to take the head version of and which
> ones to get the previous revision (committed?) of?
>
> Thanks,
> -Jeff
>
I think your question is more than just how to use svn but also how to
reorganise your build env and process? Can the shared code be put into resuable
libs? What can be seperated out as a different project and released to main
project/other applications as a library.
You could use svn:externals for managing versions of things that need to get caught
up by your build process. (where thing can be just one file or dir of a
component(library+includes+source+...)
http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.advanced.externals
Probably best to use these for things that can really be managed seperately from
the project they are use as an svn:external in.
Good example of this is in the TortoiseSVN svn repository here:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/ext/
Subversion, apr, ...
You could probably use branches/tags to control different versions of files
being released for review or deployment. So your build script doesn't have to mess
with checking out different versions.
Dev A works on branches/DevA/
Dev B and C work on branches/DevBC/
you should have trunk/ which has a baseline of your software
You could maybe have branches/development and branches/testing
Dev B&C checkin and "svn up" to get other's changes.
When changes are ready for everyone they merge to branches/development for review
Changes on branches/development merge to branchres/testing when ready.
Changes on branches/testing finally merge to trunk when finished.
Branches must merge again from trunk to get latest trunk changes when they are ready.
Disclaim! I don't know enough at all about how you work to know if this really would suit you!
The CVS redbook has a nice chapter on using branches.
http://cvsbook.red-bean.com/cvsbook.html#Going%20Out%20On%20A%20Limb%20(How%20To%20Work%20With%20Branches%20And%20Survive)
Explains things much better than I could.
The SVN book has lots of detail on working with branches:
http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.branchmerge
Getting easier to do as svn 1.5 is coming:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge
I think you could find the management of the branches is manual and a bit tricky (at the start?).
You would have to learn about how branches and merging works in svn before you could make a
good decision on how to make it part of your process. Your users also of course
would have to learn how to work with branches.
Some features in the latest release of svn (merge-tracking) make merging more usable.
We use trac http://trac.edgewall.org/ for bug/issue tracking and it also integrates with
svn and provides view on repository showing svn logs, browse source, compare revisions, ...
James.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-08 12:46:50 CEST