Thank you very much for the replies.
About export failing, it happened to me so often, I thought
"everyone" would know the details. It occurs when Windows will not
allow svn.exe export to write to the file, for any reason. The most
common reason in my case was that the file was "in use", e.g. a DLL
loaded in memory. Locking of a DLL is a Windows limitation and they
probably think it is "by design." Another thing that "locks" files
is the readonly attribute (which okay normally would not be there but
I did run into it). I have only tested the CollabNet svn.exe (command
line) in this regard. The whole thing is completely reproducible so
if you want more info on that, let me know.
RSync, why not. Good question. Because it seemed completely
overwhelming to learn another whole way of doing things, when I was
just getting my head around moving 15 years of work from 2 other
version control systems on into Subversion. Because I am only
starting to run Linux servers and did not want to put RSync there
without knowing enough how to admin it. Because when I read the info
on using RSync on Windows, it seemed to be yet another product that
did not really run on Windows, easily, simply (could be wrong about
that... ), and I really dislike the idea of simulating Linux on
Windows, not least because the instructions always assume linux
know-how and if I had linux know-how, I'd already be running it on
Linux. (End rant... just explaining why I was so turned off
RSync). Another reason was that the files were already *in*
Subversion repositories and it seemed natural to want to take them
back out of there. Does RSync automatically work against an existing
repository or would that involve having another copy of the
files? Maybe "R" stands for Repository. Obviously I don't know
anything about RSync other than it sync's something to something.
Last reason.... I thought that the spirit of CollabNet was inviting
people to collaborate, and here I really thought I had something to
contribute. And I say that because, before launching into all this,
I read quite a few forum posts from other people over the years who
also were wanting to use svn export as lazy-man's sync. It seemed so
close to being exactly that, okay if we leave aside bitmaps, all it
needed was the idea of selective export and voila, it was a sync. It
really does not seem to be as bizarre as selective export of files
containing java fragments.
As to the proposed solution of exporting everything to a temporary
location and then copying selectively (with rsync or otherwise), I
ruled that out because it needlessly duplicated all the files --
waste of disk space, processing time and effort. I did in fact do
that (with xcopy) during the weeks before Paul coded the skip feature.
Here is a link to the modified source:
http://greenbreen.com/svn_mod_source/ which implements the
--skipfilesmatchingsize feature.
-Ann
At 11:43 AM 7/15/2010, Stefan Sperling wrote:
On Thu, Jul 15, 2010 at 07:27:57AM -0400, Nico Kadel-Garcia wrote:
> On Thu, Jul 15, 2010 at 6:34 AM, Stefan Sperling <s...@elego.de> wrote:
> > Why don't you use rsync, which was designed to solve exactly
this problem?
> And, at last check as part of an attempt at an rsnapshot based backup
> system, it hangs on open files.
That is a Windows problem. Windows cannot handle deletions of files that
are open. The rsync windows ports should have special logic to deal with
this. If they don't, that needs to be fixed.
(Or even better, Windows should be fixed...)
> > I think that using a high-quality sync tool such as rsync is definitely
> > a better solution to the problem you're trying to solve.
>
> I'm mystified about using export on his core server. Do a checkout and
> svn update to a something like "SRCDIR" on the core server, to avoid
> the "this file is locked" issue, and use "rsync -av --exclude=.svn
> /SRCDIR/ REMOTEHOST:/TARGETDIR/" syntax to push only that updated
> code.
What is the "this file is locked" issue?
There is no difference between checkout and export, except that
export does not create the .svn directories.
Stefan