On 2005.05.13 13:27:46 +0000, Michael Hipp wrote:
> I develop software at 3 locations. Currently I have a large working
> folder with lots of project folders inside. Some of the projects are
> active and others are dormant.
> I've been using Unison to keep my working folder updated back to my
> Linux server and across the 3 stations. I have a script file so "one
> click" will run the Unison sync function to upload/download changes.
> Mostly this works fairly well.
> Should I get rid of the Unison scheme altogether in favor of pure Svn or
> just use Svn on top of the working folder that is being kept up by Unison?
Just use svn. Unison's functionality is redundant here. svn knows how
to get the working copy metadata right for each box. Unison will just
copy it literally, which will usually but not always be correct.
A couple of examples I can think of offhand:
* Skewed clocks. File timestamp that was the same as last update time
on the original machine is now after last update time. File appears
modified in "svn status", even though it wasn't. Then you do "svn diff"
and don't see any changes.
* svn:eol-style=native. Checkout file on Windows, get CRLF endings.
Mirror to Unix, which doesn't like CRLF endings. Usually just annoying,
but sometimes really confusing.
> What happens if I write a script that mindlessly does 'svn update' on
> each project folder even tho that project hasn't been touched? Does it
> create lots of meaningless intermediate versions or does it just skip it
> if the project has no changed files?
It just skips it.
If you put all the directories in one repository, and are able to
checkout the whole thing, then you don't even need the script. Just one
"svn update" in the parent directory, which will recurse by default.
> Any other big gotcha's with using a mindless script that runs 'svn
> update' across a bunch of folders?
Works fine. I use a script like that, but only because I'm
cherry-picking a few pieces out of a repository to build a disconnected
working copy, rather than grabbing the whole thing or a single proper
subtree. It doesn't sound like you need to do that.
David Ripton firstname.lastname@example.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat May 14 04:20:39 2005