> -----Original Message-----
> From: James Coleman [mailto:jamesc_at_dspsrv.com]
> Sent: Thursday, May 08, 2008 5:46 AM
> To: Strike, Jeff
> Cc: users_at_subversion.tigris.org
> Subject: Re: SVN Advice
>
> 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.
>
>
> This email has been scanned by the MessageLabs Email Security System.
Thanks for the info, I have the link for the svnbook and I've been
reading through that. I'll dig through the CVS chapter on branching.
Branching is something we've discussed here but I think it's only going
to get us 90% of the way there. The other 10% is probably just going to
be us establishing procedures and methods for what we push and when.
Thanks,
-Jeff
NOTICE - This message and any attached files may contain information that is confidential and/or a subject of legal privilege meant only for use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this message in error please notify the sender immediately and delete this message.
This email has been scanned by the MessageLabs Email Security System.
---------------------------------------------------------------------
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-09 17:08:00 CEST