>
> Along these same lines, I have to ask why are you putting your
> Subversion repository on a server that is not physically located at
> the
> location where you do development and/or the company you work for can
> physically and personally control the security of it?
>
Folks from New York to Colorado need to access and commit to the
repository
> It would be wiser to have that remote/hosting server use a working
> copy
> of the repository rather than THE repository. Then the remote/hosting
> server could connect over the network via https or ssh+svn to your
> local
> network to get updates. You've said yourself, you're trying to keep
> someone from stealing the entire repository or destroying it.
Wrong, I said I didn't mind them stealing it as long as they couldn't
easily get at the source.
> If they only get a snapshot of what your repository looked like at
> a point in
> time, did the thieves gain anything and did you loose anything? After
> all, in another thread you said that you just don't want to create
> everything from scratch again.
Again, wrong. I said I didn't mind creating from scratch as long as
they couldn't get to it. A sort of "If I can't have it no one can"
> Which begs the question, what is your
> backup methodology for your Subversion repository?
>
Currently I have a personal SVN repository and I'm the single point
of contact for everyone in the event of anything terrible. Needless
to say, it's a pain. A pain I'd want to spare any admin.
> And since you only have a working copy on the remote/hosting
> server, do
> as the others have suggested, encrypt the drive using the OS (Windows
> NTFS, Apple's HPFS, etc). If the thieves only steal the drive...
> they
> have to be really good at cracking encryption, other wise it is
> worthless. And more importantly, you can be back up and in
> business in
> a short time because all you have to do is checkout a new working
> copy.
>
I need the process to be transparent. Encrypting the drive causes
more work for system admins because every time we need to reboot,
they have to manually enter everything. Not to mention it doesn't
protect "live" data. As an old colleague used to say "anything worth
doing once, is worth automating"
>
> By moving your repository to your physical location in which you or
> your company can control the security of it and using the Subversion
> client for accessing the latest revisions, you've solved most of your
> issues.
While that may be true, it's not really an option as we're just
starting up, have little funds, and don't have static IPs. Hence our
shared hosting solution is the best we can do so as to give access to
everyone.
> Personally, I think your being to paranoid about this. So
> unless your working for a Fortune 500, financial institution or a
> government agency, ask yourself, is your code really worth that
> much to
> 'Jimmy the script kiddie'? Is your code worth anything to your
> competitors if there are any?
You're allowed an opinion, but frankly I'm not concerned what you
think. My only concern is what's possible. I honestly don't believe
it's that huge of a problem. And again, as I've said: Just because
it's not being done, doesn't mean it can't or shouldn't be. I
believe on-disk encryption is a great and useful idea to have
incorporated into SVN.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 21 00:17:37 2007