[jitsi-dev] git instead of svn?


#1

I'm just wondering if there has been any consideration for migrating
ice4j and Jitsi to a git repository?

I currently use git-svn to track ice4j.
- It lets me make commits even when I am offline (e.g. on a plane)
- It lets me make my changes on a private branch and keep using them
even before they are accepted into the main repo

However, git-svn adds slightly more complexity than just pure git


#2

Hey Daniel,

I'm just wondering if there has been any consideration for migrating
ice4j and Jitsi to a git repository?

There have been previous discussions yes. Basically, it would require
effort to migrate the repository and all the build machines, it would
add to the learning curve and anyone who's really set on using git can
do so with git-svn.

On the other hand people that do not like the way git works would not
have the choice of using and svn-git :wink:

Also, there used to be somewhat limited support for git in the various
IDEs on the various platforms.

I currently use git-svn to track ice4j.
- It lets me make commits even when I am offline (e.g. on a plane)
- It lets me make my changes on a private branch and keep using them
even before they are accepted into the main repo

However, git-svn adds slightly more complexity than just pure git

Right, other than removing this slight complexity, I really don't see
what advantages git or any other distributed VS would bring to the way
we work in the Jitsi community.

On the other hand it would increase complexity and it would require a
migration effort that right now we simply cannot spare, given that we
are trying to roll out video conferencing, a new GUI, and an android
version :wink:

Cheers,
Emil

···

On 15.07.12 00:32, Daniel Pocock wrote:


#3

I currently use git-svn to track ice4j.
- It lets me make commits even when I am offline (e.g. on a plane)
- It lets me make my changes on a private branch and keep using them
even before they are accepted into the main repo

However, git-svn adds slightly more complexity than just pure git
    

Right, other than removing this slight complexity, I really don't see
what advantages git or any other distributed VS would bring to the way
we work in the Jitsi community.

Actually, git is a lot more well engineered than SVN, for example,
- the way it uses hashes as commit IDs,
- the signing of tags,
- performance for large projects

I understand there is a learning curve and a migration effort

The other motivation that I had in mind is the use of git submodules,
e.g. if ice4j was in a git repo, I could declare that as a submodule of
the lumicall repo:

     http://git-scm.com/book/en/Git-Tools-Submodules

Obviously SVN also supports this in the form of externals - however,
with more and more open source projects shifting to git, the submodule
approach is something to anticipate, even if there is no immediate change

If you were willing to convert ice4j as a first step, I'd be happy to
help with the migration effort, I've documented it here already:
http://www.pocock.com.au/migrating-a-sourceforge-project-from-subversion-to-git


#4

Just one further comment on this... I imagine you will want to publish
the Jitsi Android app in the F-Droid market. They use git as part of
their build process:

  http://gitorious.org/f-droid/fdroiddata/trees/master/metadata

although I notice that their tool seems to be able to pull things from
SVN repos by using git-svn:

http://gitorious.org/f-droid/fdroiddata/blobs/master/metadata/android.androidVNC.txt

I'm planning to put Lumicall in there and that is one of the reasons why
I'm looking at ice4j and the submodule approach.

···

On 15/07/12 02:04, Daniel Pocock wrote:

  

I currently use git-svn to track ice4j.
- It lets me make commits even when I am offline (e.g. on a plane)
- It lets me make my changes on a private branch and keep using them
even before they are accepted into the main repo

However, git-svn adds slightly more complexity than just pure git
    

Right, other than removing this slight complexity, I really don't see
what advantages git or any other distributed VS would bring to the way
we work in the Jitsi community.

Actually, git is a lot more well engineered than SVN, for example,
- the way it uses hashes as commit IDs,
- the signing of tags,
- performance for large projects

I understand there is a learning curve and a migration effort

The other motivation that I had in mind is the use of git submodules,
e.g. if ice4j was in a git repo, I could declare that as a submodule of
the lumicall repo:

     http://git-scm.com/book/en/Git-Tools-Submodules

Obviously SVN also supports this in the form of externals - however,
with more and more open source projects shifting to git, the submodule
approach is something to anticipate, even if there is no immediate change

If you were willing to convert ice4j as a first step, I'd be happy to
help with the migration effort, I've documented it here already:
http://www.pocock.com.au/migrating-a-sourceforge-project-from-subversion-to-git


#5

Hey Daniel,

I currently use git-svn to track ice4j.
- It lets me make commits even when I am offline (e.g. on a plane)
- It lets me make my changes on a private branch and keep using them
even before they are accepted into the main repo

However, git-svn adds slightly more complexity than just pure git
    

Right, other than removing this slight complexity, I really don't see
what advantages git or any other distributed VS would bring to the way
we work in the Jitsi community.
  
Actually, git is a lot more well engineered than SVN, for example,
- the way it uses hashes as commit IDs,
- the signing of tags,
- performance for large projects

I don't doubt that, however we simply aren't having any issues with
SVN's poorer performance and engineering.

I understand there is a learning curve and a migration effort

The other motivation that I had in mind is the use of git submodules,
e.g. if ice4j was in a git repo, I could declare that as a submodule of
the lumicall repo:

     http://git-scm.com/book/en/Git-Tools-Submodules

Obviously SVN also supports this in the form of externals - however,
with more and more open source projects shifting to git, the submodule
approach is something to anticipate, even if there is no immediate change

OK, we'll keep that in mind. Until then, you could probably try
mirroring Jitsi in a git repo of yours and declaring that as a
submodule. (Maybe you could even do that without the mirror, via git-svn )

If you were willing to convert ice4j as a first step, I'd be happy to
help with the migration effort, I've documented it here already:
http://www.pocock.com.au/migrating-a-sourceforge-project-from-subversion-to-git

The actual repository migration is not really an issue. However, we also
need to migrate the build system and we would need to force git on all
developers (and make them migrate their own sandboxes). I am not saying
that this is a titanic effort but it is an effort none the less and it
is not going resolve any problem or bring any noticeable improvement to
Jitsi.

We will of course switch to git as soon as we actually need it.

Emil

···

On 15.07.12 02:04, Daniel Pocock wrote: