Kean Johnston wrote:
>>message. You can imagine the trivial arguments such as "get a better
>>filesystem", "fix your tools", "use 'svn export' for builds, not a
> Believe you me, I wish I COULD get a better filesystem. But I can't.
> This is an old product. It doesn't even have vnodes, so I can't even
> BUY filesystems like vxfs, let alone port any of the free ones. But
> thank you for the tip on svn export. I missed that, and you are right,
> for build machines that indeed fixes the problem completely. It MAY
> even fix it for developers too. Since most of the tree is read-only
> to most developers, perhaps they can export the tree, and then
> svn checkout those portions where they will be doing real work. Is
> there any problem with mixing and matchign exported and checked out
> trees? I ask before I try because that's easier :)
I nearly suggested 'svn export' earlier but the disadvantage is that
you're not going to get any kind of diffy update. The next day when you
need to build HEAD again, you're going to have to a complete checkout.
But since you say bandwidth is not an issue for you maybe this is fine.
As for whether they'll play nice together... I'm guessing you won't be
able to check out parts because they'll be obstructed, but that is a
pretty minor issue. Either you can come up with some set of command
line flags to overwrite them (does --force do this?) or write a set of
scripts to help you with this process. You can certainly check out part
of the repository into the middle of a filesystem that contains an
exported tree. The problem, however, is that you can't go to the top
level and do "svn update".
So it may not be an ideal situation in either case, but it might be
workable with a little thought (particularly in the case of automated
build machines, which is what I was originally going to suggest it for).
Beta4 Productions (http://www.beta4.com)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Dec 17 12:55:09 2002