Post a Comment
Subversion does a good job at this. But after trying Darcs I just can't bring myself to use it. Subversion is really just toasty CVS and as good as it was, these days it's starting to burn. Unfotunately Darcs is not so good for huge projects (like your entire file system). But Git may be the answer. I hear they've been borrowing ideas from Darcs, and it's much more to the metal. Git is on my list of tech to try. Curious what other's think.
(Of course with a little luck eventually revision control will be built-in to our filesystems)
Unfortunately, most 'documents' these days are binary files with a lot of information in them the user doesn't know or care about.
This makes viewing changes between revisions and resolving conflicts harder for 'documents' (as opposed to for plaintext files).
It'd be sweet if, say, openoffice had builtin support for CVS/SVN/etc, including a `proper' implementation for reviewing changes and resolving conflicts in the document types it supports.
But aren't ODF files just a bunch of XML(plain text) documents inside a gz compressed file?
Technically, yes. So the 'external diffing tool' should at least unzip the document and diff the plaintext files inside.
However, a standard plaintext diffing tool will perform poorly: some ODF processing tool might have, for example, re-formatted the whitespace in the file. You want the diffing tool to be robust against that.
Even then, when your version of an ODF document conflicts with the version on the server, you don't want to be presented with the XML internals of the document. It is hard to read and harder to edit correctly. You want to see the changes using a tool that understands ODF and presents the differences in a user-friendly way, i.e. marking text sections etc.
OpenOffice already has some nice versioning features, but afaik it hasn't been made usable for CVS/SVN/... yet. All I'm saying: that would be really cool.
Interesting how 2/3 of the article is devoted to setting up an svn server. If you use Git (http://git.or.cz), it's more like:
git init-db
git commit file
You can publish a git tree with Apache and access it remotely via the http:// protocol without any special server setup by just dumping the repository in a directory, or use the git:// protocol for better compression.
The full Wine repository is 85Mb in Git and over 500Mb in svn.
gitweb can be installed on a server to give similar functionality to cvsweb, and gitk and qgit are local graphical tools.
Edited 2006-09-03 02:45
for those who want to save their documents on a safe place, using subversion on a webhost can be convenient way to do it ( i use dreamhost.com, 25 Gb of space, you just have to tick a box to install subversion).
check or ask if your webhosting can be used with subversion.
i put all my important documents there (tax, pictures, letters, backup..)
I wouldn't put anything sensitive like tax information on a webhost that is shared by other people, which is what dreamhost is. Unless of course, the documents were encrypted, and that would make SVN a little pointless, since it would just store the binary encrypted file.
It is so difficult to secure a server against someone who already has an account on the server. If you have an account on the server, not only will the remote exploits work, but so will the local exploits, or perhaps a security mechanism is just misconfigured.
I keep my tax things encrypted even on my personal computer!
does someone else has the same opinion than pojo about the (in)security associated with a shared webhosting ?
i always though it was secure enough
I share this opinion in general, i don't know about dreamhost specifically.
Not saying you shouldn't use shared hosting, for most uses it's great, but for security-sensitive stuff I wouldn't recommend it.
If the shared server has PHP or SSH support, it is quite probable that other hosters can at least read your data. Note that in many cases that isn't a problem at all though, and in that case shared webhosting is 'secure enough'.
I used to run a shared webhosting service, so I know a little about the pitfalls of a shared environment. Unless they are using multiple virtual machines on the same host, it is likely they they will be able to read the files in your account (Usually because the web server has access to read your files, and so they can write a web script to peruse them).
If the web server is set up to only run under your username then it's a little better, but at the very least you still have to worry about the people who are administrating the machine. Can you trust them to not go rooting through your files?
I figure I just don't even want to tempt some bored, underpaid system admin, so I don't put anything sensitive where they can get it.
Just my 2 cents. But it's usually always safer to be paranoid when it comes to computer security.
I would argue that a file system with the following capabilities is enough for home user needs (with regards to maintaining important files)
a. Taking a snapshot reliably.
b. Having multiple snapshot capability.
c. Access restore any snapshot.
You can always scale from this solution to web based solutions, if the need arises.
ZFS is one file-system capable of doing the above. Other file-systems may hold similar capabilities. However, it is not my intention to start a file-system debate, merely to exhibit other alternatives, simpler in my opinion.
Yes ZFS is awesome, I will be the first to admit it. But it is not a replacement for source code management.
zfs snapshots have some limitations, they are for a whole filesystem, even if you give one filesystem for each project, you can't snapshot a single file. and their is no place for notes, which source code managers encourage, for why a snapshot is important. version1.0 or version1.1 won't help you figure out why did I make a change 6 months ago. You can also look at the complete history of a file which can be very important long term.
layering source code management on top of ZFS could turn into a powerful tool. Setting up a script to snapshot the project every 15 minutes can be a way to recover from a mistake like accidently deleting a file or reverting to a previous version that you didn't check in but should have.
source code managers also have better tools for accessing files remotely, you can access earlier versions and diffs between any of them, not to mention the reasons for changes to the file in a web browser, where zfs only lets you see earlier versions but not the differences between the versions.




.