hi,
i did not mean to use git as svn client, but use git as storage format
for svn client. do you then still think all your points below hold?
currently our full svn working copy has 250.000 files and directories,
with git it is 30.000. and as the working copy is personal, nobody is
able to create the missing 220.000 files that easily.
with svk the whole thing is no problem ... but there are people
critizing it a little cause of "additional install work" and "no gui"
(no eclipse plugin, no tortoisesvk).
but, svk can be used like cogito/git, monotone, codeville. and anyway
uses a svn backend.
-solo.
On 6/20/05, David Waite <dwaite@gmail.com> wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 20 21:18:22 2005