The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
It's not what your program can do, it's what your users do with the program.
It's not what your program can do, it's what your users do with the program.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:Actually, that's not Spanish, it's Portuguese, I believe.
I'm not 100% certain, but I think SVN has good enough file locking that concurrent access by multiple users via filesytem access (as opposed to something like the svn server) is safe. That is, of course, as long as you use the standard svn utilities and not some brute-force code of your own. Subversion itself was designed for atomic version control.
If 2 people attempt to commit the same file at the same time, there should be a conflict which would require resolution. That is true whether updating via svn client program, apache http or the svn server. So for that particular product, you'd be safe on a single repository. But I'm not so sanguine when rsyncing, especially if both versions are being updated. A better solution is to keep one repository as the active one, mirror to the other copy and switch only when the primary goes down.
Incidentally, I use drbd to mirror my repositories and that's pretty much how drbd works except at the block device level and not at the file level. I make actual (svndump) backups daily and I don't worry TOO much about lost data in the interim, since I also have a backup of sorts in the original desktop working copy I did the commit from (and in the case of IDEs such as Eclipse, also the daily local history).
Last time I installed a Jira server, I was using Oracle as its backing database, although that's not the only DBMS you can use. That particular system was on a SAN with RAID disks and tape backups. Mirroring databases is generally fairly tricky and should be done with database-specific tools and not simply rsyncing, as there's a chance of file corruption otherwise.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |