Probably not a working copy, it is a filesystem-based object database
for representing version trees. It could make sense as a svn_ra
mechanism, or as an interchange format (svnadmin dump option.) I did
some investigation of this and concluded
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.
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.
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.)
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.
-David Waite
On 5/27/05, solo turn <soloturn@gmail.com> wrote:
> hi,
>
> would git (http://www.kernel.org/pub/software/scm/git/docs/git.html)
> somehow fit into svn for making a "better" working copy?
>
> -solo.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 27 18:52:53 2005