My apologies if this has already been suggested.
I can't help but wonder why developers don't test locally. Apache
usually runs just fine on Windows, although you might need an unusual
feature. We use this methodology because each developer can operate
independently and not be bottlenecked by one server. A lot can be done
to mirror the production environment with virtual host configurations
and such. This would remove the steps requiring the web server's working
copy which appears to be the root of the problem.
Hope that helps,
Kevin
JC Hearn wrote:
> Ok, I see what you mean.
>
> However, from the developer-user perspective, it is different. If the
> developer-user SSH's into the box and runs the CLI, if FEELS to them as if
> they are checking out the working copy to a remote box.
>
> Let me share with you the crux of the problem. We have an existing workflow
> which I am hoping to not have to change too much (from the developer-user
> perspective). (Keep in mind that we are an ASP, so everything has to be
> tested in context on the web server.)
>
> Current workflow:
>
> 1. Developer uses Dreamweaver to lock and download one or more files.
> 2. Developer changes files. (Other developers can view but not modify.)
> 3. Developer uploads files (but still has lock).
> 4. Developer tests files on web server.
> 5. Developer may make additional changes but eventually checks in file.
> 6. File is now available to other developers to modify.
>
>
> Envisioned workflow with CLI (There should be a way to do this workflow with
> a GUI):
>
> 1. Developer uses CLI to check out module to private workspace on remote
> server. (This private branch of the tree is kept up to date by Subversion.)
> 2. Developer uses Dreamweaver as above (download, modify, upload, test),
> without lock issues.
> 3. Developer commits changes to repository from remote private branch on
> remote server.
>
>
> Envisioned workflow with (ass backward) GUI:
>
> 1. Developer uses GUI to check out module to local workspace (local hard
> drive).
> 2. DEVELOPER WILL THEN HAVE TO UPLOAD THE ENTIER MODULE BACK TO THE WEB
> SERVER TO A TESTING FOLDER, SINCE DREAMWEAVER WON'T KNOW WHAT HAS CHANGED.
> 3. Developer uses Dreamweaver to modify, upload, and test.
> 4. Developer uses GUI to commit changes to repository from local workspace.
>
> I think this is unworkable. Unless there is a GUI that can do the second
> workflow (above), we will have to teach all the developers the CLI. (Not
> impossible, just somewhat difficult and should be unnecessary.)
>
> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Sunday, January 23, 2005 10:38 PM
> To: JC Hearn
> Cc: 'Branko Čibej'; 'Peter McNab'; users@subversion.tigris.org
> Subject: Re: Subversion GUI client?
>
>
> On Jan 23, 2005, at 9:28 PM, JC Hearn wrote:
>
>
>>Well, now, hold on a sec. I thought that if I used the CLI, I could
>>have
>>the working copy be on the same box (remote server). Am I wrong about
>>that?
>
>
> I think you're confused about svn clients.
>
> There's absolutely no difference between a commandline client and a GUI
> client. There's exactly one subversion client API, and all clients use
> that API. So all clients are *functionally* identical, though the UIs
> may look different.
>
> Generically speaking, "a subversion client" creates a workspace
> (working copy) on a locally mounted volume. It could be local disk, or
> it could be a network share. Whether the client is CLI or GUI is
> irrelevant.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
----------
Scanned for viruses by ClamAV
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 24 06:51:32 2005