On Jan 23, 2005, at 10:07 PM, 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:
Calling our common case "ass backward" isn't really going to help you
win any popularity contests around here. :-)
> 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.)
Ah! Now I think I understand.
First, if you want to keep your existing workflow, you're likely going
to have to write a custom GUI client.
Second, if you're willing to change your workflow, you can use
Subversion (by having users work on a private branch, and having some
mechanism to trigger an "update" to their private branch website on the
server (perhaps on commit). This would allow them to have a local
working copy and commit changes to the server (thereby avoiding
scenario 2 (the ALL-CAPS scenario).
Third, what do you use now for your "existing workflow?" Another
version control system? If so, which one?
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 24 07:17:39 2005