Re: SVN Access to Lua source and other assorted libraries

[David Kastrup <dak@...>]

"RJP Computing" <rjpcomputing@gmail.com> writes:

>     >     > "RJP Computing" <rjpcomputing@gmail.com> writes:
>>     >
>>     >     > OK. So far I don't see any Subversion access to Lua, so
>>     >     > I think this makes my decision easy. git, bazaar, and
>>     >     > Mercurial are all great. I don't want to offend anybody
>>     >     > or start a discussion about what version control system
>>     >     > to use. I just need Subversion access to the files. I am
>>     >     > not an expert, but so far I can't find a way to use a
>>     >     > Bazaar/git/Mercurial repository with an svn client.
>>     > Huh?  "git svn dcommit" will commit to SVN just fine.
>>     > Yeah, I am talking about the other way around. Make a git
>>     > repository and allow svn clients to commit and such.
>> Why?  Just import every tarball into git, and then push into the
>> central SVN repository everybody is going to work with.  git will
>> reconstruct the rename/move history and SVN will be glad to receive
>> and exhibit it.  In short: just use git as your private toolkit in
>> order to import new versions into SVN.
>
> I guess my brain can't understand what you are trying to say. :) If I
> can restate what I think you are saying is to make a git repository
> somewhere on the public internet.

No.  What about "private" did you not understand?

> (I don't know of any free git hosts) Then use that as the external
> repository and then I import the git into our local svn repository.

git does not usually work with a separate repository.  It keeps the
history locally.

> If this is correct, I can't see any benefit. It actually makes it
> harder for the repository admin.

Nonsense.  The "repository admin" never gets to see git.

> If I just do the same suggestion, only use svn, I can use Subversions
> ability to include externals and just get the code directly from the
> internet svn repository.

Huh?  There is no Internet SVN repository of Lua where you could "get
the code".  The whole point of your request was that you wanted to
_create_ such a repository.

> Can you explain why that is better then using svn?

Huh?  I am telling you to use git for creating and maintaining a SVN
repository and you ask my why this is better than using SVN?  You _will_
be using SVN with my proposal.

> And I am not talking about reasons one version control is better then
> the other. I am tring to understand why it matters if I use the
> philosophy of coping the tarball to a git repository or to a svn
> repository.

git records only snapshots and reconstructs copies/moves from the
snapshots.  SVN records a whole copy/move history.  But you only have
isolated tarballs to start with, basically.  So in order to import your
stuff into SVN, you need to reconstruct this sort of history.  git is
good at doing that.  SVN has no tool for it.  So by passing your
snapshot tarballs through git on your local computer and then pushing
the resulting history with git svn dcommit into the Subversion
repository, Subversion gets to know what was copied/moved where when.

Without such a step, Subversion won't know when a file moved from one
place to another and won't tell you about the differences across the
move.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum