You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Gale, David" <Da...@Hypertherm.com> on 2005/11/17 17:54:57 UTC
Single Developer, Distributed Development Environment
I was just talking with one of my fellow developers about the project
she's working on, and how she's not sure subversion is capable of doing
what she needs it to. I've come up with two answers, which I'll detail
below; can anyone think of anything better?
The Problem: She needs to modify the files she's working on through a
tool that's only available for her Windows desktop, but she can only
test the modifications once they're on a Unix box. (They're a
proprietary binary format.)
Her current workflow is to FTP the file(s) she needs to her box, edit,
save with an increasing id number, ftp that file/files to the test
system, test, edit on her machine, ftp, test, etc., until she has a
working version.
Possible Solutions:
Create a branch, switch the testing system, switch her working copy,
make changes, commit to the branch, update the testing system, test,
make changes, commit, update, test, etc., and eventually merge back to
production. Downsides: the repository's revision number would take off,
she's doing two steps (commit & update) where before she did one (ftp),
and the repository would be full of non-working versions.
Or, checkout a working copy to her desktop, make changes, save with an
increasing id number, ftp to the testing system, test, make changes,
ftp, test, etc., and commit her working copy once she's got a good
version. I like this version better, though one thing I like about
subversion is that you don't need to use ftp anymore, which this process
wouldn't allow.
Anyone have any better ideas?
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Single Developer, Distributed Development Environment
Posted by Andy Levy <an...@gmail.com>.
On 11/17/05, Gale, David <Da...@hypertherm.com> wrote:
> I was just talking with one of my fellow developers about the project
> she's working on, and how she's not sure subversion is capable of doing
> what she needs it to. I've come up with two answers, which I'll detail
> below; can anyone think of anything better?
>
> The Problem: She needs to modify the files she's working on through a
> tool that's only available for her Windows desktop, but she can only
> test the modifications once they're on a Unix box. (They're a
> proprietary binary format.)
>
> Her current workflow is to FTP the file(s) she needs to her box, edit,
> save with an increasing id number, ftp that file/files to the test
> system, test, edit on her machine, ftp, test, etc., until she has a
> working version.
>
> Possible Solutions:
> Create a branch, switch the testing system, switch her working copy,
> make changes, commit to the branch, update the testing system, test,
> make changes, commit, update, test, etc., and eventually merge back to
> production. Downsides: the repository's revision number would take off,
> she's doing two steps (commit & update) where before she did one (ftp),
> and the repository would be full of non-working versions.
>
> Or, checkout a working copy to her desktop, make changes, save with an
> increasing id number, ftp to the testing system, test, make changes,
> ftp, test, etc., and commit her working copy once she's got a good
> version. I like this version better, though one thing I like about
> subversion is that you don't need to use ftp anymore, which this process
> wouldn't allow.
That sounds overly complex. I'm not terribly experienced with svn
yet, but why not set up the repository on the Unix box and have her
work with it via TortoiseSVN? Then, write a post-commit hook script
that grabs the file from the repository and drops it where she's
FTPing it today?
Failing that, run the repository on another server (or even her
desktop), and have a post-commit script FTP the file to the Unix box?
Most command-line FTP clients can be scripted easily, or you could
probably find a Perl or Python module to do it in-script.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Single Developer, Distributed Development Environment
Posted by Duncan Murdoch <su...@murdoch-sutherland.com>.
On 11/17/2005 12:54 PM, Gale, David wrote:
> I was just talking with one of my fellow developers about the project
> she's working on, and how she's not sure subversion is capable of doing
> what she needs it to. I've come up with two answers, which I'll detail
> below; can anyone think of anything better?
>
> The Problem: She needs to modify the files she's working on through a
> tool that's only available for her Windows desktop, but she can only
> test the modifications once they're on a Unix box. (They're a
> proprietary binary format.)
>
> Her current workflow is to FTP the file(s) she needs to her box, edit,
> save with an increasing id number, ftp that file/files to the test
> system, test, edit on her machine, ftp, test, etc., until she has a
> working version.
>
> Possible Solutions:
> Create a branch, switch the testing system, switch her working copy,
> make changes, commit to the branch, update the testing system, test,
> make changes, commit, update, test, etc., and eventually merge back to
> production. Downsides: the repository's revision number would take off,
> she's doing two steps (commit & update) where before she did one (ftp),
> and the repository would be full of non-working versions.
That would work, but has the problems you've identified.
>
> Or, checkout a working copy to her desktop, make changes, save with an
> increasing id number, ftp to the testing system, test, make changes,
> ftp, test, etc., and commit her working copy once she's got a good
> version. I like this version better, though one thing I like about
> subversion is that you don't need to use ftp anymore, which this process
> wouldn't allow.
>
> Anyone have any better ideas?
I'd think the simplest solution would be to work with one checked out
version of the file. Find a way (samba?) to mount the Unix directory in
Windows, then edit it in place. Skip the ftp step.
If samba isn't available, then the workflow she's already using seems
workable, except for the "increasing id number" part. Check out the
file on the Unix system. Copy it to the Windows system. Edit, copy
back, test. Edit again, copy again, test again. When it finally works,
go to Unix and commit the last version to the repository.
Why bother with new filenames each time? She's just using the Windows
box as a very inconvenient Unix editor.
By the way, there are nice ssh implementations available on Windows
(Putty, OpenSSH, SSH) which support keypair authentication; those are
probably more convenient to use and certainly more secure than ftp would
be.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Single Developer, Distributed Development Environment
Posted by Phil Endecott <sp...@chezphil.org>.
Gale, David wrote:
> The Problem: She needs to modify the files she's working on through a
> tool that's only available for her Windows desktop, but she can only
> test the modifications once they're on a Unix box. (They're a
> proprietary binary format.)
If you can't use Samba or WebDAV (see other posts), note that some VNC
implementations have a file transfer facility.
--Phil.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Single Developer, Distributed Development Environment
Posted by Joerg Hessdoerfer <Jo...@sea-gmbh.com>.
Hi,
On Thursday 17 November 2005 18:54, Gale, David wrote:
> I was just talking with one of my fellow developers about the project
> she's working on, and how she's not sure subversion is capable of doing
> what she needs it to. I've come up with two answers, which I'll detail
> below; can anyone think of anything better?
>
> The Problem: She needs to modify the files she's working on through a
> tool that's only available for her Windows desktop, but she can only
> test the modifications once they're on a Unix box. (They're a
> proprietary binary format.)
>
> Her current workflow is to FTP the file(s) she needs to her box, edit,
> save with an increasing id number, ftp that file/files to the test
> system, test, edit on her machine, ftp, test, etc., until she has a
> working version.
>
> Possible Solutions:
> Create a branch, switch the testing system, switch her working copy,
> make changes, commit to the branch, update the testing system, test,
> make changes, commit, update, test, etc., and eventually merge back to
> production. Downsides: the repository's revision number would take off,
> she's doing two steps (commit & update) where before she did one (ftp),
> and the repository would be full of non-working versions.
>
> Or, checkout a working copy to her desktop, make changes, save with an
> increasing id number, ftp to the testing system, test, make changes,
> ftp, test, etc., and commit her working copy once she's got a good
> version. I like this version better, though one thing I like about
> subversion is that you don't need to use ftp anymore, which this process
> wouldn't allow.
>
> Anyone have any better ideas?
>
> -David
Errr, yes, why?
1.)
Isn't it possible to setup a SAMBA server on the Unix box? This way you'd
avoid the FTPing - just edit the file on the Unix box directly (from the
Windows machine, in case this isn't clear ;-).
Use your favourite SCM (read: SVN) to VC it.
If she can't setup a SAMBA server, what about an SMB client doing it the other
way 'round?
2.)
Use SVN over apache as WebDAV server with autoversioning. That'd be easiest
for a workflow, but she would have the version number issue.
3.)
Use apache as WebDAV server, to replace the SAMBA in scenario 1.)
These came to mind immediately. Somebody have other ideas?
Greetings,
Jörg
--
Leading SW developer - S.E.A GmbH
Mail: joerg.hessdoerfer@sea-gmbh.com
WWW: http://www.sea-gmbh.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org