Re: Substituting existing mechanism with Subversion--help!!

Siju,

We have the same nasty setup at our company, and I asked a similar
question back in December:

http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=22914

After numerous responses and thinking things through, I think I've
decided on a similar approach to what Peter describes:

Instead of making /var/www available via Samba, there will be a
mechanism (a web control panel, maybe) that allows developers to check
out the project from the repository. This working copy gets created on
the same server, but in a directory in /var/www/userX (or more likely
/home/userX/htdocs). The developer works on this copy, using his own
private web address to verify his work, and when done, does a check-in.
A post-commit hook will do an automatic check-out back to /var/www so
that what Peter calls the "smoke test" site always has the most current
version.

The next problem is what happens when a developer needs to work on
several different unrelated things, and each of these need buy-off from
the project manager before being commited to the project, and such
approval can sometimes take a week, during which the developer needs to
be able to work on other things. I have some ideas, but I have a
feeling that reading further in the SVN book, to the section on
branches, will replace my fuzzy notions with better concrete ones.

We also have MySQL databases for almost all projects, and tracking
changes in them is going to be more difficult. It would seem to be
necessary for each developer to have their own copy of the database,
just as they have their own copies of the PHP files, but this is
problematic from a time and disk-space perspective for some of our
larger databases. Assuming that this can be solved, responses to my
question provided two avenues of tracking changes. One was manually
keeping track of all SQL changes in a text file (which can be applied
to, say, the live system after testing in the development system) and a
parallel file listing the SQL statements to *reverse* the action (which
can be applied to the live system to revert to a previous version,
should the new version prove to be broken) -- this solution is clear to
me and may be what we end up using. The other suggestion which bears
investigation was http://www.mysqldiff.com/ -- but at this point I
haven't even downloaded it yet.

-- 
ryan schmidt // hello at ryandesign dot com
On 07.01.2005, at 00:15, Peter Valdemar Mørch wrote:
> Do you realize you've asked a very broad question? I'll answer as best 
> I can as time allows:
>
> Siju George sgeorge.ml-at-gmail.com |Lists| wrote:
>> There is a Debian Server hosting the projects files in the apache home
>> directory.
>> ie all websites that are developed are put in differrent folders in
>> the "/var/www" directory
>> The "/var/www" directory is shared
>
> > If so could you please guide me with the set up process?
>
> What you basically have is one directory where everybody is stepping 
> on each others feet. This is *nasty*! Each developer can not debug in 
> peace with all the changes going on by others. It depends *a little* 
> on how often changes actually take place. But don't do this.
>
> I suggest:
>
> Each developer has his own "Debian Server" with his own /var/www 
> directory. (Which could be the same "Debian Server" with 
> /var/www/userA,  /var/www/userB, etc.). All these /var/www (or 
> /var/www/*/) directories are in fact individual working areas.
>
> Once develper A is happy about his change in his own working directory 
> (which is now totally independent of what developer B is doing) he 
> checks in his modifications. It is every developer's responsibility to 
> keep up to date with other developers' changes with svn update.
>
> You can then have a single integration area, that e.g. is updated 
> every morning to make sure that everything is up to date. Call it the 
> "smoke test" site.
>
> If you insist on having only the one shared directory, in my 
> experience, you'll never reach "stability". But if you insist, you can 
> then have only that one single working area, and agree that whenever 
> someone puts a file in there, he needs to check it in. But somebody is 
> going to forget that at some point, and you have no way of knowing 
> who. Don't do this.
>
> Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org