On Wed, 26 Jan 2005 14:14:40 -0500, Dassi, Nasser <NDassi@141xm.com> wrote:
>
> [snip]
> The web site needs to have *a* working copy (or exported filesystem);
> this doesn't mean that all developers must work in that same working
> copy. Most people find this sort of setup very frustrating to use,
> because it's impossible for one developer to isolate his changes from
> the others'.
>
> Also, any changes made to that one working copy affect *everyone* in
> real-time. If one developer leaves a bug in his code and leaves for the
> day, no one can get their work done until he fixes it.
> [/snip]
>
> 1. Since Dreamweaver is their standard tool of choice as IDE, then let us remember that Dreamweaver is able to lock resources via .LCK files.
An acceptable solution in some cases. Subversion is getting locking
support to allow users to have this effect even when editing their own
local copies.
> 2. Isolating changes is not really sandbox-friendly, eh?! Obscurity is not really a good thing on ultra-high-priority web projects.
What do you mean by this statement? Isolating changes means that two
people aren't debugging the same pages/code at one time, and being
influenced by each-other's side effects. Developers can fully
implement and test their individual task before committing, meaning
the version of the web site within source control should always work.
> 3. If a developer leaves a bug for another day... Then he should get fired. Employment security is taken for granted, and those who do not play nice in the sandbox deserve to get penalized for not doing their work (like documenting a bug for other people to see what is still buggy about their code). --> SVN does a great job in their bug tracking website at discussing what is in the works for each bug.
You must have either very long workdays or very simple development
tasks for developers to be able to fix any possible bug and add any
feature completely in under one day. They must also live in terror of
saving their work, because the script may not get interpreted
correctly and prevent everyone else from viewing their work until the
problem is tracked down and fixed.
Subversion, CVS, and other versioning systems are meant to solve the
_fundamentally_flawed_ idea of requiring every developer work in the
same physical development environment to get around source code
synchronization problems. The ability for a developer to write and
test their fixes without concern for leaving things in a non-working
state over lunch or affecting other people's debugging is an extremely
good thing.
- David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 27 02:43:58 2005