You misunderstand me; I was talking about using git in an environment
it already is similar to - the repository file format. Using it for a
proper svn wc is quite frankly, impossible. Why impossible?
- No support for properties
- No support for mixed revisions
- No support for character encoding
- No support for remote edits (copying a file on a server)
- No support for locks
- Geared toward completely different operating model than svn today,
resulting in complete tool changes.
Given that (I suspect) _none_ of these are planned for the git format,
I doubt any of these differences will go away. The format of a git
repository is very rigid even at this early stage.Thus, this is not a
drop-in replacement of working copy code. Usually changes of this
magnitude result in a complete new tool (something like cogito)
Plus, do not bash 10 files in svn - in git you create a new file for
every version of every file, every version of ancestor directories of
changed files, every commit, and every 'tag'. Since working copies are
actually distributed branches, a local copy winds up mirroring all the
versioning of each of the branches it pulls from. Ten files is
_nothing_ compared to mirroring large portions of a remote repository.
Also, git will make any fragmentation problem with the filesystem far
worse. The files are keyed by sha-1 hash - quite clever, but it means
that there is zero locality at the file system level. A checkout can
span millions of files with no rhyme or reason, just sha-1 pointers
going everywhere.
Not to say cogito is a bad tool or git is a bad format, I actually
have been using both for some small projects to get more familiar, and
follow cogito with my own branch. It is just a completely different,
incompatible model from subversion, and the 'working copies' of the
two show it.
-David Waite
On 6/20/05, solo turn <soloturn@gmail.com> wrote:
> thanks a lot!
>
> On 5/27/05, David Waite <dwaite@gmail.com> wrote:
> > Probably not a working copy, it is a filesystem-based object database
> i liked linus torvalds "3 sec is one sec too much" opinion on speed:
> http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=3322&Thread=206&entryID=49699&roomID=11
>
> and our main problem (on windows) is the working copy speed and file
> system defragmentation.
>
> > 1. Copy/rename tracking is implicit in git - file contents are indexed
> > by the sha1 hash of the contents, so a copy/move can only be tracked
> > if there is a commit without change to the file contents. Thus, it
> > would probably be necessary to represent copy/renames as two distinct
> > commit objects in git in order for copy/moves to be inferred.
> hmm. no solution comes into my mind.
>
> > 2. Git has no concept of a repository version number (feature, not a
> > bug - it uses sha1 hash values based on the contents of a revision's
> > tree, and has commit objects representing the transition between
> > trees). This may be possible to indicate with tags, but could cause a
> > lot of excess tags.
> but svn could store the hash in a property? or key?
>
> > 3. Git has no concept of metadata such as svn properties. The data
> > model would probably need to be extended to support such a concept
> > (although a specially-named file could be an appropriate hack.)
> anything should be better than the 10 files and directories per
> file/dir stored now :))
>
> > 4. Branches in subversion are just filesystem subdirectories, while
> > git has them as parallel full trees. This is the real sticking point I
> > believe. While you could use git as a format, you would be operating
> > in a different manner than considered appropriate, and would not want
> > to expose this database to other tools.
> but you can freely decide to create one or not? svk also uses a local
> storage for merge and branch information.
>
> -solo.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 20 17:05:51 2005