[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: git as svn working copy?

From: David Waite <dwaite_at_gmail.com>
Date: 2005-06-20 22:29:01 CEST

Just to clarify, you mean git having code to pull and push to
subversion http/svn/file repositories?

-David Waite

On 6/20/05, solo turn <soloturn@gmail.com> wrote:
> 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 22:29:51 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.