martin f krafft wrote: > It has corrupted my repositories often. I was using Subversion for > about 3 or 4 years.
Ok, this is a personal experience. I don't know what may have happened to your repositories, but I would be interested, since I work with this. For me, I got corrupted repositories only twice with Subversion. The first time was a bug in a very early version of the BDB backend (before version 1.0). That backend was really ugly in many ways, and thanks for the Subversion people for the much more reliable FSFS backend (available from v1.1 onwards). The second time was due to a hardware failure. I manage a number of Subversion repositories for a few companies, for about 6 years. Although I got hit by other bugs, these were the only repository corruptions I did experience. The second corruption had a 1-day window from the last backup, and this gave me some headache in order to replicate the lost commits. Of course that would be a no-problem if it were a DVCS, but that is another story. There are people that say that Subversion is unreliable because Git does cryptographic checks (the SHA-1 identifier). But it happens that Subversion also does a hash checking of the contents in a very similar way, but this information is completely hidden in the backend (and never used as a commit identifier). Subversion is able to properly detect repository corruption just like git, but with a drawback: since usually only the last revision is touched, a corruption in the early revisions may stay unnoticed for a long time. Now, corrupted working copies are a lot more common. But this is easy to work around. > So you have a centralised repository. What do you do when you are on > an airplane? How do you write to the filesystem? So, you are calling the repository a filesystem, this led me to misunderstand you. For me, a filesystem is contained in a hard disk partition, mounted somewhere in my directory tree. When you said that with Subversion you can't access the filesystem if you are not connected, it seemed like you were confusing Subversion with something like Perforce, where you have to mount a network filesystem locally and use it as your working copy (well, in the case of Perforce, it seems that there is a way to work offline, but I don't know details). You can work offline with Subversion, no problem here. It doesn't inhibit you from doing your work, but you will have to refrain from committing until you have your connection back. Your statement in the other message made it seem like you are completely hindered if you are offline. Also note that there are different features mixed together here, that are not exclusive for distributed VCSes. There are plans to add offline commits to Subversion, even though it will stay (at least for the planned future) as a centralized VCS. > I use Git for homedir versioning. How does it fail for you? Not only Git, I tested Mercurial too, and it also failed in similar ways. 1. Both don't see directories. Just because a directory is empty doesn't mean that it doesn't exist. If I delete all files in a directory, it doesn't mean that that directory ceased to exist. Some programs don't expect this. For example, file all messages from your Inbox, and commit. Then you pull from the other machine, and your Inbox directory just disappears. 2. Both lack proper ways to store metadata. This is evidenced by the need to pollute your directories with .gitignore, .gitattributes and .gitmodules (for Git), and .hgignore, .hgbranches and .hgtags (for Mercurial). All this information is threated and versioned as part of the contents of the repository, while it should not. It is the plumbing of the VCS that gets exposed and mixed with the user files. Mercurial is really sad in this point. It gets confused (and the user gets confused too) if you have different .hgbranches and .hgtags in different branches. It gets even worse when you have to merge two branches and get merge conflicts in any of these files. In the case of Git, .gitattributes is a huge misfeature. The attributes stored in it are user-edited, and is not attached to the actual files. If you move files around, you suddenly lose your attributes until you fix the attributes file. 3. As a consequence of the above limitation, if you want to store some extra metadata that is not tracked by the VCS, like file permissions, there is no place to put them unless you create more files. Subversion offers properties, so I have my pre-commit and post-update scripts (in fact, they are little hacks... I have to rewrite them sometime) that store groups and permissions into properties attached to the actual files and directories. I can move and copy files and their properties are moved together. I could also extend this idea to track xattrs and advanced ACLs directly from the Linux filesystem. 4. Git only: lack of real rename/copy support. This affects not only vcs-home, but also general SCM use; it is just worse for vcs-home. There is a much bigger likelihood of having binary files in your home than common source code projects (what Git was designed to manage). Images, text documents, spreadsheets, presentations, compressed files, etc... For example, you change a single character in an ODF document and save. You will see that the file is completely different binary-wise, not easy to track. If you also rename before the commit, you just lose the connection, and there is nothing you can do about it. For me, the above is the worst misfeature "by design" of Git, and exactly the reason why I prefer Mercurial over Git (while I don't step onto any of Mercurial bugs). It is even disturbing: you have the precise information, here, now, that you just renamed the file, but there is absolutely no way to store this information in Git. You commit and the information is lost, forever. Ten years from now, when you go back through the history of your repository, you won't remember anymore that that file changed its name, and will depend on heuristics with arbitrary thresholds to detect the rename. The last two below... > Git supports unicode filenames and binary files as large as you want > them. 5. Git doesn't actually support Unicode filenames (neither does Mercurial). Both just store whatever the file name is in the filesystem directly into the repository, as just an array of bytes. You won't notice this unless you create files with names containing characters beyond the ASCII set, and use different encodings in different computers. This also causes problems when cloning your repositories to systems that are Unicode-aware (like Windows and MacOS X).  http://code.google.com/p/msysgit/issues/detail?id=80  http://kerneltrap.org/mailarchive/git/2008/1/16/573827 I have files with names in Portuguese (which contains acutes, graves, circumflexes, umlauts, tildes and cedillas), and also a few ones in Japanese. Although UTF-8 should now be the default for Linux, many people (well, I say for Portuguese speakers at least) configure their systems to ISO-8859-1, because that was what was used everywhere until some time ago, and that is what Portuguese-language Windows installations store in FAT32 filesystems (very common in pen-drives). Syncing repositories using Git or Mercurial between systems using different encodings is a nightmare. Git doesn't even respect LANG and LC_CTYPE, and expect everything (including commit messages) to be in UTF-8 no matter what the user have set his system to. Mercurial is a little better, since it encodes and decodes commit messages properly, failing only to filenames. Subversion and Bazaar do the right thing. 6. Git really is fine with large files, but Mercurial specifically doesn't handle big files well. Just hg add a file > 10MB and see the warning it presents you. > Anyway, as I said a couple of times in all different places: use the > tool that suits you. You wanted feedback on fsvs and I told you what > I thought of it. I am also interested in what your experiences are > or will be! It was not me who wanted feedback on fsvs. It was Plamen Marinov. I just dropped in this thread because I was curious about your statements about Subversion. Back on topic, I didn't know about fsvs, and from what I see from the link, it seems something very good for our scope here. Something I will definitely test. Regards, -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead. _______________________________________________ vcs-home mailing list firstname.lastname@example.org http://lists.madduck.net/listinfo/vcs-home