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

Re: Piecemeal code deployment v/s Complete source code

From: SVN User <svn.user_at_gmail.com>
Date: 2006-03-19 16:13:30 CET

Thanks everyone for your valuable input.

On 3/17/06, KM <info4km@yahoo.com> wrote:
>
> In response to these messages I see on the users list - Just because the
> whole tree is checked out , doesn't mean you have to release everything. It
> is true that for development, it is causing us a problems figuring out
> (especially if its compiled code and not just files that are deploiyed
> (shells, perl etc)). As for the actual deployment, we plan on writing a
> script to use the update command of svn to update an area - before a
> build/deployment - and to keep track of what is updated added and deleted
> (and also built if compiling is necessary). Then only the changed files will
> be part of a deployment package.
> haven't completely figured this out yet though. - I understand your
> dilemma and questions completely. I agree -I personally did not choose
> subversion as our source control tool, but now must work with it to develop
> a build and deployment process. KM From: Rule, Chris <
> Chris.Rule_at_tbe.com<Chris.Rule_at_tbe.com?Subject=RE:%20%20Piecemeal%20code%20deployment%20v/s%20Complete%20source%20code>>
>
> Date: 2006-03-17 16:38:45 CET
> I work on a project that currently works somewhat like you describe.
> Using our current homegrown system the developers only work on the parts
> of the code that need changing and link to object libraries that
> comprise our baseline. At any given moment, each developer has in his
> working copy (his local directory) only those files he is changing.
>
> I've been looking at subversion for more than a year and still can't
> come up with a way to replicate this because you have to check out whole
> directories. There is no per-file checkout, which we would require, and
> seems to be what would be needed for what you described. I keep watching
> and hoping this feature will get implemented at some point. It's listed
> as a to-do for subversion, but keeps getting pushed back or ignored as
> not important to the current developers.
>
> Another thing you might need to consider is the effect subversion has on
> backups. The way subversion currently works each developers working copy
> is duplicated in a hidden .svn folders. For small projects this isn't a
> problem. Unfortunately, our project isn't small and backups are a
> current problem even without having the full project checked-out and the
> duplicate copy.
> I suspect most applications developed where the developers are not
> co-located use the complete source code development method. It seems to
> be the more common method.
>
> ________________________________
> From: SVN User [mailto:svn.user@gmail.com]
> Sent: Friday, March 17, 2006 7:34 AM
> To: users@subversion.tigris.org
> Subject: Piecemeal code deployment v/s Complete source code
> This is not a subversion issue, but I thought I might ask it here as
> some people might have been past this situation.
> We are using a legacy Financial application, which was developed using
> Cobol. Since there was no version control tool in the past, we just
> implemented Subversion.
> The developers here are used to moving only changes to QA & Production,
> They do not move the complete Tagged source code.
> I wanted to know if anybody still practices this piecemeal method of
> code deployment or is it complete source code moved & compiled at once.
> Thanks for any input.
> Received on Fri Mar 17 16:40:20 2006
>
> ------------------------------
> Yahoo! Travel
> Find great deals<http://us.lrd.yahoo.com/_ylc=X3oDMTFscDlocTFiBF9TAzMyOTc1MDIEX3MDMjcxOTQ4MQRwb3MDMgRzZWMDbWFpbC1mb290ZXIEc2xrA3l0LXR0/SIG=12hqieud9/**http%3a//leisure.travelocity.com/Promotions/0,,YHOE%7c1381%7cvacs_main,00.html>to the top 10 hottest destinations!
>
>
Received on Sun Mar 19 16:14:32 2006

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.