On Jun 3, 2005, at 8:52 AM, trlists@clayst.com wrote:
> On 3 Jun 2005 Ben Collins-Sussman wrote:
>
>
>> Why not let the version control system do this for you? Instead of
>> copying files around yourself based on timestamps, why not just have
>> a working copy on each machine? Then all you need to do is run 'svn
>> update' to get the newest things on each box.
>>
>
> Thanks Ben. I knew someone would say that :-).
>
> That works fine for that purpose. It is a significant change in
> practice but I could get used to it.
Well, using version control means changing your practices. There's
no such thing as transparent version control. :-)
>
> - Right now the repository is stored locally on one machine. Can
> I access it from the other across the (Windows) network using
> file:/// syntax if the repository drive is mapped?
If the repository is FSFS-backed, rather than BDB, then it's fine to
access directly via file:/// over a network share. Otherwise: why
not just run a trivial 'svnserve' daemon and use a real network?
It's dead simple to set up, and will probably work faster than SMB.
>
> - I manage the transfer of all kinds of other files between
> machines with a single script that uses timestamps. This approach
> would require using svn for all the files under version
> control, so
> it doubles the complexity of updating.
Doubles the complexity? Just use your current script for unversioned
things. Use 'svn commit' and 'svn up' for the versioned stuff; the
svn commands don't even need to be part of a script.
>
> - Using svn update requires a commit on one machine before
> updating on the other. I switch back and forth between machines
> sometimes 2 or 3 times a day, and often I'm not ready to commit
> the work when I just happen to need to switch machines. IOW the
> version control cycle and the between-machines update cycle are
> poorly matched. .
I'm not sure I understand; is there some difference between "commit
changes" and "copy files from one machine to another?" Either you're
ready to broadcast work to other computers, or you're not.
In the old system, you would copy stuff over via timestamps. In the
new system, you would 'svn commit', and then 'svn update'.
>
> - Using svn handles only the files under version control. How do
> I also handle unversioned files in the directories that are under
> version control.
Keep using your timestamp scripts, I guess.
>
> - There are other things I do with timestamps -- for example
> understanding if two files were changed at about the same time or
> not, looking at which files I need to upload to deploy the changes
> to my live site, etc. The way svn manages the timestamps makes
> this difficult.
The 'live site' issue is so common, it's even an SVN FAQ:
http://subversion.tigris.org/faq.html#website-auto-update
Basically, you have a post-commit hook run 'svn update' on a live
working-copy after every commit. You get automatic publishing of
whatever has changed.
>
> So it is a lot more than just saying "use svn update". It could be
> done, but it adds a lot of complexity to what is currently a
> relatively
> simple process.
>
Um, your current process sounds anything but simple to me. :-)
The problem is that we're both speaking in generalities. Maybe if
you posted a detailed description of your workflow, others on this
list could prescribe a new process for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 3 16:27:57 2005