I am using fsvs and just found svnhome in google...

[Juliano F. Ravasi]

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[1] and MacOS X[2]).

[1] http://code.google.com/p/msysgit/issues/detail?id=80
[2] 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.