On 3 Jun 2005 Ben Collins-Sussman wrote:
> Well, using version control means changing your practices. There's
> no such thing as transparent version control. :-)
Fair enough :-).
> 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 could do this if I wanted to. My network consists of four Windows
machines; and two Linux machines (fileserver and firewall), both
running Slackware. I normally access the fileserver from Windows via
SMB but I could put the repository on there easily and use svnserve.
However, since I currently store in on one Windows machine and don't
mind opening it for sharing inside the network, leaving it there and
using file:/// from the other also works, and as they say it ain't
broke.
> 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.
Right now I can update with a single command (with which I have to
interact). Using svn for part of the update requires using a different
approach for those directories, and that is more complex.
> 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.
The two computers are both used by me. One is a desktop and one is a
laptop. I move back and forth between them often, depending on where,
how, and when I'm working, and whether I need to take work out of the
house. I tend to use commit when I'm done with something, which is not
at all synchronized with switching machines.
> > - 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.
Well yes, but then that script needs to know not to muck with the files
svn is updating. I'd have to put them in a separate directory, another
complexity.
> 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.
Thanks, I will look at that. I would need multiple updates as I have
both live and development sites on remote servers, and live and
development branches in the repository.
> Um, your current process sounds anything but simple to me. :-)
Ah, but I can do it without having to hardly think about it at all :-).
> 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.
Well sure, here is a typical transfer:
- Do some work on project files
- Look at clock
- Uh oh, have to be at that meeting across town in 15 minutes,
then I'm going to pick up the kids, maybe I'll sit at the
library for the hour in between
- Better take the laptop
- Save files, in whatever state they're in, marking location of
current effort (usually I just stick a marker in the source)
- Close editor on desktop
- Open laptop
- Run update script to pick up changed email, project files,
correspondence, images, etc. from desktop -- only about
10% of what's copied is under version control
When I get back this is typical:
- Start work on laptop in dining room while kids play
- Oops, time to clean up for dinner
- Realize that I'll be working on desktop later
- Close editor, etc., as above
- Run update script to put what I did for the afternoon back on
desktop
You get the idea, I hope. Most of what's transferred is not under
version control, and when it is really all I'm doing in svn terms is
keeping the working copy in the same state on both machines, but
commiting little changes and half-done files does not seem to me to be
what VCS is or should be for.
The original problem here was being able to preserve timestamps, for
which I have a number of fairly conventional and legitimate uses.
Significantly altering my work practices to get the benefits of VCS
makes sense. But having to use VCS to keep my laptop synchronized with
my desktop 2 or 3 times a day is not the benefit I want from VCS, it's
added complexity for no actual benefit that I can see. If I'm changing
my practice purely to work around the way a tool is designed, and
adding complexity for no benefit just so I can do that, that seems to
me like the tail wagging the dog.
On the other hand, one might conclude from the above that svn is not
the right tool for the job I'm trying to do, but everything else I
looked had other problems that were even worse ...
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 3 17:23:51 2005