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 problems when > cloning your repositories to systems that are Unicode-aware (like > Windows[1] and MacOS X[2]). If you store the encoding along with the filename, you'll run into a whole lewd of other issues when transcoding. My solution to this is just to have UTF-8 everywhere. I am all too glad to have waved goodbye to all those encoding nightmares that were iso8859-* and ascii. > 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. I think this is a feature. If we keep adding backwards-compatibility layers to tools, we not only make them bigger, more error-prone, and harder to maintain, but we also slow down the transition to better times. -- martin | http://madduck.net/ | http://two.sentenc.es/ "'the answer to the great question...' 'of life, the universe and everything...' said deep thought. 'is...' said deep thought, and paused. 'is...' 'forty-two,' said deep thought, with infinite majesty and calm." -- hitchhiker's guide to the galaxy 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