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

[Plamen Marinov]

Hi all,

Sorry I am bit late with my answer. Few notes from me (as beginner):

1. I understand git and svn have advantages and negatives (I do not 
understand everything that was said)

2. I understand 'offline commits' are good feature. Instead commit 
everything at once (when I become online), it is better to do few small 
commits (each commit with it own commit message).

Looks like git have this feature 'build in'. I think (I am begineer with 
both linux and fsvs) it could be easy to 'get status' and 'copy all 
changed files' to separate temp directory. Once you become online, you 
could easy do commit all temp directories. (Of course, if there are big 
files, these temp directories will require some space).

I understand it is kind of work around.

3. No one talk about 'versioning meta data' like mode, group, owner, 
last modified time. This feature is build in fsvs.

regards,
Plamen.



_
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[martin f krafft]

also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.28.0153 +0100]:
> This is starting to get way of topic... If anyone is bothered with this
> discussion, just say so and I will continue off-list.

You might want to change the thread subject, then I can adjust the
archives. :)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
minchinhampton (n.): the expression on a man's face when he has just
zipped up his trousers without due care and attention.
   -- douglas adams, the meaning of liff
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[Juliano F. Ravasi]

Aristotle A. wrote:
> The standard Shift_JIS encoding cannot be mapped to Unicode
> without ambiguities.

This is starting to get way of topic... If anyone is bothered with this
discussion, just say so and I will continue off-list.

> Worse, there is a whole range of variants
> of this charset that all go by the name of Shift_JIS, yet map
> codepoints that are unused in the official Shift_JIS standard
> to different characters. If you have something labelled
> Shift_JIS, you cannot safely convert it to Unicode without
> risking data loss.

Yes... Shift_JIS is a mess while people use proprietary extensions, that
Unicode doesn't recognize. But the problem is no more of Unicode than it
is from Shift_JIS itself.

But the industry standard JIS X 0213 aims to fix this problem, and
converge Shift_JIS to something sane. Unicode provides round-trip
conversion for JIS X 0213 since version 3.0 or so... Yes, I just
confirmed. Here [1][2] are the mapping tables between JIS X 0213:2004
and Unicode. Also, I found [3] that discusses many of these problems of
Japanese encodings, and confirms that Unicode 3.1 provides lossless
conversion for JIS X 0213.

[1] http://x0213.org/codetable/sjis-0213-2004-std.txt
[2] http://x0213.org/codetable/jisx0213-2004-std.txt
[3] http://www.jbrowse.com/text/unij.html

The problem is that many people still use JIS X 0208 with proprietary
extensions... It is more or less the same problem that many people still
use ISO-8859 when we already have UTF-8...

> The problem is that on Unix, at least, the filesystem actually
> gives you nothing but octet sequences. The only invalid filenames
> are ones containing slashes or nulls. Everything else is fair
> game. Filenames can be any random garbage whatsoever.

Yes... This is something that Unix could improve a lot.

> Take a look at the contortions that the GNOME people had to go
> through for the file selector dialog and similar things where
> gtk+ and friends touch upon the filesystem.

Yes, I know the KDE/Qt side of this opera. KDE quite overkilled in this
point... the code that handles URL-escaping and local filename encoding
is the same. As a consequence, KDE allows you to put "/" in filenames.
It transparently converts back and forth to "%2f" for you in the filesystem.

> Then from a SCM design point of view the question turns into
> this: do we want to the repository to be unable to store some
> actual files that some users may conceivably have good reason to
> have? (See Shift_JIS mess above.)

I think that this is somewhat expected, specifically for Shift_JIS, due
to the problems above. In fact, the user is already forced to restrict
to some subset of Shift_JIS, because you need screen fonts that display
the characters. Using characters that are in proprietary extensions will
always leave you open for ambiguities: you change the font and your
filenames change. You must either restrict yourself in what characters
you use, or upgrade to JIS X 0213 and enjoy full compatibility with Unicode.

> The problem space is unfortunately much bigger and messier than
> what you have portrayed in your mail. IMO the fact that git punts
> is regrettable, but also pretty much inevitable, so it is not
> something that I hold against git. There is simply no truly sane
> way of untangling this incredibly ugly yarnball.

Well, Windows does it (NTFS is UTF-16 encoded, and Windows of course
supports Shift_JIS), MacOS X does it, Subversion does it, Bazaar does it...

It is possible and feasible to support Shift_JIS encoding... you may not
be able to store all possible filenames, only those that are standard
and convertible to Unicode, but possible nevertheless.

-- 
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
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[Aristotle Pagaltzis]

* Juliano F. Ravasi <[EMAIL PROTECTED]> [2008-08-27 04:05]:
> 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.

You can work around this right now by putting an empty .gitignore
in the directories that you don’t want to lose.

That said, git’s model (I don’t know about hg’s) is not
fundamentally incapable of mapping empty directories. The code
has just not been written that way, and so far, none of the
people who might have wanted empty directories to be preserved
has actually taken the time to patch git to do it, so it remains
an open issue, to be addressed whenever someone needs it badly
enough that they do the work.

At least, that was the state of play on the git mailing list last
I checked. Admittedly that was a while ago, so I have no idea if
they have changed their minds on any of it.

Regards,
-- 
Aristotle Pagaltzis // 
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[Aristotle A.]

* Juliano F. Ravasi <[EMAIL PROTECTED]> [2008-08-27 19:55]:
> Unicode (and thus UTF-8) is a superset of all encodings. It is
> required by the specification of the Unicode that any
> conversion X->Unicode->X MUST be lossless. It is important to
> keep in mind that Unicode has versions, and that some writing
> systems are only fully supported by some Unicode versions.
> 
> Due to the complexity of some writing systems, Unicode allows
> that the same character sequence be represented by more than
> one way. For example, "ü" (u-umlaut) may be represented by
> U+00FC alone, or by the sequence U+0075 U+0308. But for any of
> such ambiguities, there is *always* the one of them that is the
> "normalized" version (the normalized one may change from one
> version of Unicode to another, but this is usually avoided
> whenever possible).
>
> So, for proper Unicode support, you must forbid any
> non-normalized UTF-8 input for filenames, so that there is
> always unique character sequences stored in the repository, and
> there will always be unique conversions to any other encoding.
>
> So, it doesn't hold true that it is possible to encode
> something to UTF-8 and get errors when converting it back. Of
> course, Unicode->X conversion fails if the Unicode sequence
> contains characters that are not present in X, this is
> something to expect. But the X->Unicode conversion MUST be
> valid and MUST have an unique representation, whatever X is.

Would that all this were true.

The standard Shift_JIS encoding cannot be mapped to Unicode
without ambiguities. Worse, there is a whole range of variants
of this charset that all go by the name of Shift_JIS, yet map
codepoints that are unused in the official Shift_JIS standard
to different characters. If you have something labelled
Shift_JIS, you cannot safely convert it to Unicode without
risking data loss.

There is nothing that the Unicode consortium can do about this
either, since the problem is that Shift_JIS is a mess, not that
the Unicode mapping for it or Unicode’s character coverage is
somehow defective. The problem is unfixable.

“I swear, text will be the death of me.”
—Dan Sugalski, initial Parrot VM lead architect, in
 http://www.sidhe.org/~dan/blog/archives/000281.html

>> Treating everything as a sequence of bytes is far safer (not
>> to mention faster) than converting everything every time it's
>> commited or checked out.
>
> Sure it is faster, but I don't think it is safer. See the
> problems that Git and Mercurial present when they are ported to
> systems that expect all filenames to be clear and valid Unicode
> sequences.

The problem is that on Unix, at least, the filesystem actually
gives you nothing but octet sequences. The only invalid filenames
are ones containing slashes or nulls. Everything else is fair
game. Filenames can be any random garbage whatsoever.

Take a look at the contortions that the GNOME people had to go
through for the file selector dialog and similar things where
gtk+ and friends touch upon the filesystem.

> Safer, for me, is to forbid the addition to the repository of
> any file name that is known to give problems when converted to
> any other encoding. Forbid the inclusion of any data
> incompatible with the users LC_CTYPE, including non-normalized
> UTF-8.

Then from a SCM design point of view the question turns into
this: do we want to the repository to be unable to store some
actual files that some users may conceivably have good reason to
have? (See Shift_JIS mess above.)

The problem space is unfortunately much bigger and messier than
what you have portrayed in your mail. IMO the fact that git punts
is regrettable, but also pretty much inevitable, so it is not
something that I hold against git. There is simply no truly sane
way of untangling this incredibly ugly yarnball.

Sorry. :-((

Regards,
-- 
Aristotle Pagaltzis // 
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[martin f krafft]

also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.1843 +0100]:
> What? There is nothing there that even resembles a fuse
> filesystem. Are we talking about the same thing?

I mixed it up with something else then. Sorry for that.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"i feel sorry for people who don't drink. when they wake up in the
 morning, that's as good as they're going to feel all day."
-- frank sinatra
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[Juliano F. Ravasi]

[Sorry Benjamin, the message was supposed to go to the list]

Benjamin M. A'Lee wrote:
> There is a good reason for this, and it's explained in the git-log
> manual page: it's not necessarily possible to convert something to UTF-8
> (or any other Unicode encoding) and convert it back without introducing
> errors, especially with some less-commonly-used character sets.

Unicode (and thus UTF-8) is a superset of all encodings. It is required
by the specification of the Unicode that any conversion X->Unicode->X
MUST be lossless. It is important to keep in mind that Unicode has
versions, and that some writing systems are only fully supported by some
Unicode versions.

Due to the complexity of some writing systems, Unicode allows that the
same character sequence be represented by more than one way. For
example, "ü" (u-umlaut) may be represented by U+00FC alone, or by the
sequence U+0075 U+0308. But for any of such ambiguities, there is
*always* the one of them that is the "normalized" version (the
normalized one may change from one version of Unicode to another, but
this is usually avoided whenever possible).

So, for proper Unicode support, you must forbid any non-normalized UTF-8
input for filenames, so that there is always unique character sequences
stored in the repository, and there will always be unique conversions to
any other encoding.

So, it doesn't hold true that it is possible to encode something to
UTF-8 and get errors when converting it back. Of course, Unicode->X
conversion fails if the Unicode sequence contains characters that are
not present in X, this is something to expect. But the X->Unicode
conversion MUST be valid and MUST have an unique representation,
whatever X is.

> Treating
> everything as a sequence of bytes is far safer (not to mention faster)
> than converting everything every time it's commited or checked out.

Sure it is faster, but I don't think it is safer. See the problems that
Git and Mercurial present when they are ported to systems that expect
all filenames to be clear and valid Unicode sequences.

Safer, for me, is to forbid the addition to the repository of any file
name that is known to give problems when converted to any other
encoding. Forbid the inclusion of any data incompatible with the users
LC_CTYPE, including non-normalized UTF-8.

Note that this is not a real problem for Git while you use it for what
it was designed to be: an SCM. You should never use files outside the
ASCII set for your source code files, unless you are really expecting to
have problems. This just becomes an issue when Git is used for storing
other things.

> Not true. Though I don't know about LANG and LC_CTYPE support, it's
> certainly not true that Git expects UTF8 no matter what; you can
> override the i18n.commitencoding and i18n.logoutputencoding settings as
> necessary.

Ok, I missed these options. I don't know if they are new or if I just
missed them when I read the documentation for the first time. Well, it
makes Git a little less bad. It stores the encoding along with the
commit message (without conversion), and tries to recode to whatever
output encoding is requested during the log output.

It still breaks the expected behavior that every other locale-aware
software conforms to. I.e., the output these two commands should provide
proper, different outputs:

LC_ALL=en_US.UTF-8  git --no-pager log
LC_ALL=en_US.ISO-8859-1 git --no-pager log

Compare with, for example:

LC_ALL=pt_BR.UTF-8  iconv --help | head
LC_ALL=pt_BR.ISO-8859-1 iconv --help | head

(the second one should display some broken characters if your system is
UTF-8, that is expected).


-- 
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
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[Juliano F. Ravasi]

martin f krafft wrote:
> No, I meant what I said: fsvs is presumably a fuse-filesystem and
> mounted under ~.

What? There is nothing there that even resembles a fuse filesystem. Are
we talking about the same thing?

> Am I misunderstanding fsvs?

It seems so...

-- 
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
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[martin f krafft]

also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.0302 +0100]:
> 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.

No, I meant what I said: fsvs is presumably a fuse-filesystem and
mounted under ~. It being a Subversion-backed filesystem, there has
to be some repository behind it all. This can either be local, in
which case you cannot really synchronise between two machines
independently (unless you treat one machine as a central node), or
you won't be able to use (commit to) the filesystem when offline.

Am I misunderstanding fsvs?

> 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.

Well, if I am making changes to the filesystem, I want to have them
committed. From what you suggest, it seems as if fsvs requires some
external command to be run to actually make commits, in which case
you'll end up with gigantic, unrelated commits after working on your
files on e.g. a transglobal (= long) flight.

[Git stuff left for a separate mail]

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
man muss noch chaos in sich haben
um einen tanzenden stern zu gebähren.
-- friedrich nietzsche
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

(valid) criticisms of Git addressed (was: I am using fsvs and just found svnhome in google...)

[martin f krafft]

also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.0302 +0100]:
> 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.

If you emptied your inbox, why keep it around? I expect the tools
I use to recreate empty directories aqs needed.

This is apart from the fact that I prefer to use IMAP for
synchronising mail, since it's a better tool (made) for the task and
can do stuff (like flags) better than a mail-agnostic tool, such as
a content tracker.

> 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.

This is a very valid point and I wish Git had a metadata layer. I've
tried to bring up the issue with the developers, but they're not
interested in making Git more generic ("it's used to track the linux
kernel sources, if you use it for anything else, you are on your
own").

But keep in min that Git, Mercurial & Co. are first-generation (if
you are willing to place arch into the zeroth generation, and see
Monotone in a league of its own). We are surely going to see new
tools which pick up on these issues in the future.

There is one thing to be said in favour of in-filesystem metadata,
such as .gitattributes — conflicts in those are no different than
conflicts in content files, and all of the standard and advanced
conflict resolution mechanisms (merge drivers, git-rerere, etc.) can
be used for those just as well. Surely, this could be remedied by
exposing the metadata layer as files in the event of conflicts, but
that would be a hack in my world, and likely come with other
problems.

> 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.

Agreed.

> 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.

Git doesn't track the file, it tracks the content. If you make small
changes, it's likely that the two blobs will be compressed to little
more than the size of one in the store. When it comes to keeping the
association (e.g. log messages), Git uses commit history anyway to
figure this out.

> If you also rename before the commit, you just lose the
> connection, and there is nothing you can do about it.

This has not happened to me before, or well, it's not bitten me.

Do you mean something like:

+lapse:~/.tmp/cdt.VLULwrjW|master|% echo foo > testfile
fatal: No HEAD commit to compare with (yet)
+lapse:~/.tmp/cdt.VLULwrjW|master|% git add testfile
gfatal: No HEAD commit to compare with (yet)
+lapse:~/.tmp/cdt.VLULwrjW|master|% git commit -m'add testfile(foo)'
Created initial commit 3ff1892: add testfile(foo)
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 testfile
+lapse:~/.tmp/cdt.VLULwrjW|master|% echo bar >| testfile  
changes on filesystem:
 testfile |2 +-
+lapse:~/.tmp/cdt.VLULwrjW|master|% git mv testfile someotherfile
cached/staged changes:
 someotherfile |1 +
 testfile  |1 -
+lapse:~/.tmp/cdt.VLULwrjW|master|% git commit -m'moved the file to 
someotherfile(bar)'
Created commit 78b242f: moved the file to someotherfile(bar)
 2 files changed, 1 insertions(+), 1 deletions(-)
 create mode 100644 someotherfile
 delete mode 100644 testfile
+lapse:~/.tmp/cdt.VLULwrjW|master|% git log -- someotherfile 
commit 78b242f2d5df1ebe96e25e2dc6c69eb1c135cbb2
Author: martin f. krafft <[EMAIL PROTECTED]>
Date:   Wed Aug 27 13:55:37 2008 +0100

moved the file to someotherfile(bar)

> 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 pro

Subversion corruption (was: I am using fsvs and just found svnhome in google...)

[martin f krafft]

also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.27.0302 +0100]:
> 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.

I do not recall the details, but I've had numerous occasions where
I'd have to dump and restore the repository with svnadmin because
some obscure errors prevented me from using the repository.

I have never had a problem with Git or mercurial.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"i am not in favour of long engagements. they give people the
 opportunity of finding out each other's character before marriage, 
 which i think is never advisable."
-- oscar wilde
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[Benjamin M. A'Lee]

On Tue, Aug 26, 2008 at 11:02:40PM -0300, Juliano F. Ravasi wrote:
> martin f krafft wrote:
> > 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).

So if your system is wrongly configured to use a non-UTF8 encoding, the
filenames break. (Or, rather, they break until you set a UTF-8 locale;
any errors aren't permanent.)

There is a good reason for this, and it's explained in the git-log
manual page: it's not necessarily possible to convert something to UTF-8
(or any other Unicode encoding) and convert it back without introducing
errors, especially with some less-commonly-used character sets. Treating
everything as a sequence of bytes is far safer (not to mention faster)
than converting everything every time it's commited or checked out.

> 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.

Not true. Though I don't know about LANG and LC_CTYPE support, it's
certainly not true that Git expects UTF8 no matter what; you can
override the i18n.commitencoding and i18n.logoutputencoding settings as
necessary.

-- 
Benjamin M. A'Lee || mail: [EMAIL PROTECTED]
web: http://subvert.org.uk/~bma/ || gpg: 0xBB6D2FA0


signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: 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

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

[martin f krafft]

also sprach Juliano F. Ravasi <[EMAIL PROTECTED]> [2008.08.26.2207 +0100]:
> > If you are fine with the slow speed and all the other limitations
> > of Subversion, give it a shot. I haven't, and I wouldn't touch it
> > because I don't trust Subversion.
> 
> Gratuitous Subversion bashing?

Not intended, no.

> May I ask why you don't "trust" Subversion?

It has corrupted my repositories often. I was using Subversion for
about 3 or 4 years.

> What? Are you sure you meant that? You can't use the filesystem if
> you are not connected?

So you have a centralised repository. What do you do when you are on
an airplane? How do you write to the filesystem?

> distribution is needed). In fact, I already knew that git and hg
> would fail for the task, since I already knew them very well for
> SCM before starting my vcs-home experiments.

I use Git for homedir versioning. How does it fail for you?

> code projects (only files and not directories are important, no
> need to support unicode filenames, most files are very small,
> etc). That is

Git supports unicode filenames and binary files as large as you want
them.

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!

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
http://lavender.cime.net/~ricky/badgers.txt
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[Juliano F. Ravasi]

martin f krafft wrote:
> If you are fine with the slow speed and all the other limitations
> of Subversion, give it a shot. I haven't, and I wouldn't touch it
> because I don't trust Subversion.

Gratuitous Subversion bashing?

May I ask why you don't "trust" Subversion?

> Also, since Subversion can't
> actually operate in offline mode, you either need to be connected to
> use the filesystem, or you only get a local repository that you
> cannot sync with another machine, which kinda defeats the whole
> point for me.

What? Are you sure you meant that? You can't use the filesystem if you
are not connected?

If your intention is to sync between machines, you NEED to have a
connection. What other means of syncing do you expect without a network
connection?

You could have said "offline commits" as a possible advantage, but that
is not syncing. Once you need to pull or push, you need a connection, no
matter if you use CVCS or DVCS. And in my particular POV, offline commit
is a wonderful feature when you do SCM, but for homedir versioning it
has very little use (of course, people are free to disagree with me...
*I* find it very useless for this purpose).

When I started planning about creating my vcs-home, the only resources
available were Joey's and Scott's articles about Subversion. I did try
myself some of the other options (svk, git and hg), and Subversion ended
being the only sane option (with some help from SVK if/when/where
distribution is needed). In fact, I already knew that git and hg would
fail for the task, since I already knew them very well for SCM before
starting my vcs-home experiments.

During my tests, most DVCSes had deficiencies that outweighed their
benefits for this task. I could list here all the problems, but they all
summarize to that virtually all of them were designed to manage source
code projects (only files and not directories are important, no need to
support unicode filenames, most files are very small, etc). That is
valid to the extent that git and hg developers advise you to not use
them for anything other than SCM. Subversion, on the other hand, is
completely agnostic about what you put in there.

To make things clear, I'm not a proponent of this or that VCS. I have
some extra experience with Subversion, sure, and I recognize its
limitations (and also its strong points). I'm just able to analyze
clearly when some tool is more suited than some other tool for this or
that task, without having my opinion influenced by some famous guy who
makes a presentation calling everyone who disagrees with him "ugly and
stupid".

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
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[martin f krafft]

also sprach Plamen Marinov <[EMAIL PROTECTED]> [2008.08.22.1404 +0100]:
> And I am not giving any advice - fsvs is better or not. I am just
> asking, if you know about fsvs, what do you think about it.

If you are fine with the slow speed and all the other limitations
of Subversion, give it a shot. I haven't, and I wouldn't touch it
because I don't trust Subversion. Also, since Subversion can't
actually operate in offline mode, you either need to be connected to
use the filesystem, or you only get a local repository that you
cannot sync with another machine, which kinda defeats the whole
point for me.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
tempt not a desperate man.
-- william shakespeare
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

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

[Plamen Marinov]

Hi,

Honestly, I did not read everything yet 
(http://joey.kitenet.net/svnhome/), but I want to ask one short and 
quick question:


Did you hear about fsvs (http://fsvs.tigris.org).

Recently I start using fsvs to version part or whole linux installation
(including home folder). I am new with linux and I am new with fsvs (my 
whole idea is not yet clear).


And I am not giving any advice - fsvs is better or not. I am just 
asking, if you know about fsvs, what do you think about it.


I did read a little about with 'restore meta data' (file permissions, 
last modified time). I found some 'commit hooks' for git. Looks like 
FSVS already have an solution. Anyone who try fsvs?


Thank you,
Plamen.

___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home