Migrate from svn to git

Hi,

I hope that is the correct list to ask some questions.
I understood that the idea behind git is completely different and I like 
the idea behind git.

But for the svn repository I want to convert I need some features and 
I'm not sure how / if to implement them in git.

Corrently the svn repo is divided into trunk branches and tags.
In each of this directory like trunk i have directories like hardware, 
software, docu and more.

For each of this subdirectories I have usergroups defined which has no 
access, read access or rw access.

If I understood the manual correctly I can stick on that structure and 
easily work here with the unix-permission to grant access to the folders?
I think I have to test then acl with freebsd to have more then one group 
for each directory.


The second question is, I someone commits some files with svn an email 
is sent to a svn-commit mailinglist so changes can easily be discussed.
The current mail is sent in html format with a colored diff, so it is 
easier to read.

Is something similar possible with git or do you suggest a complete 
approach?

Thanks a lot for answers.

Bye,
Matthias

-- 
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook

On Wed, May 26, 2010 at 15:13, Matthias Fechner [off-list ref] wrote:

I hope that is the correct list to ask some questions.
I understood that the idea behind git is completely different and I like the
idea behind git.

But for the svn repository I want to convert I need some features and I'm
not sure how / if to implement them in git.

Corrently the svn repo is divided into trunk branches and tags.
In each of this directory like trunk i have directories like hardware,
software, docu and more.

For each of this subdirectories I have usergroups defined which has no
access, read access or rw access.

If I understood the manual correctly I can stick on that structure and
easily work here with the unix-permission to grant access to the folders?
I think I have to test then acl with freebsd to have more then one group for
each directory.

No. Git isn't centralized. Anyone can clone the repo and change
anything the want. You implement control by setting a policy on what
you merge back into your tree, which is considered canonical.

There are several on-commit filtering programs available that can do
that automatically based on paths within the repository.

The second question is, I someone commits some files with svn an email is
sent to a svn-commit mailinglist so changes can easily be discussed.
The current mail is sent in html format with a colored diff, so it is easier
to read.

Is something similar possible with git or do you suggest a complete
approach?

There are a lot of these scripts available in contrib and elsewhere.

Corrently the svn repo is divided into trunk branches and tags.
In each of this directory like trunk i have directories like hardware,
software, docu and more.

For each of this subdirectories I have usergroups defined which has no
access, read access or rw access.

If I understood the manual correctly I can stick on that structure and
easily work here with the unix-permission to grant access to the folders?
I think I have to test then acl with freebsd to have more then one group for
each directory.

As far as I know, git doesn't track permissions (except for the execute bit).

The second question is, I someone commits some files with svn an email is
sent to a svn-commit mailinglist so changes can easily be discussed.
The current mail is sent in html format with a colored diff, so it is easier
to read.

Is something similar possible with git or do you suggest a complete
approach?

I've seen it done, e.g. xfce4-commits mailing list.
http://foo-projects.org/pipermail/xfce4-commits/

On Wed, May 26, 2010 at 11:13 PM, Matthias Fechner [off-list ref] wrote:

For each of this subdirectories I have usergroups defined which has no
access, read access or rw access.

If I understood the manual correctly I can stick on that structure and
easily work here with the unix-permission to grant access to the folders?
I think I have to test then acl with freebsd to have more then one group for
each directory.

Dealing with acl sounds like a lot of work and complications to me.
Have a look at gitolite. It is covered quite nice in the progit book [1]

The second question is, I someone commits some files with svn an email is
sent to a svn-commit mailinglist so changes can easily be discussed.
The current mail is sent in html format with a colored diff, so it is easier
to read.

Is something similar possible with git or do you suggest a complete
approach?

For this you might want to look at Gerrit [2]. It's a web-based code
review. Although it is not email based (AFAIK).

nazri.


[1] http://progit.org/book/ch4-8.html
[2] http://code.google.com/p/gerrit/

Am 26.05.10 19:04, schrieb Nazri Ramliy:

Dealing with acl sounds like a lot of work and complications to me.
Have a look at gitolite. It is covered quite nice in the progit book [1]
   

thanks for the link i will read the documentation to get more 
information about it, but the first look is very promising.

Matthias

-- 
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook

Am 26.05.10 18:23, schrieb Ævar Arnfjörð Bjarmason:

There are a lot of these scripts available in contrib and elsewhere.
   

thanks, i will start then in the contrib folder.
Is it possible in git to attach script like hooks in svn if someone pull 
content to the repo?

Matthias

-- 
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook

On Wed, May 26, 2010 at 10:13, Matthias Fechner [off-list ref] wrote:

The second question is, I someone commits
some files with svn an email is sent to a
svn-commit mailinglist so changes can easily
be discussed.

Shouldn't the discussion happen before the commit?

The current mail is sent in html format with
a colored diff, so it is easier to read.

I would rather receive the raw diff and let my own preferred tools
display the information in way that I personally like.

Keep in mind that `git diff' is capable of displaying the diff with color.

Michael Witten

Hi Michael,

Am 31.05.10 14:01, schrieb Michael Witten:

Shouldn't the discussion happen before the commit?
   

in most of the cases it is not necessary, but the diff mails are used as 
an additional review step and sometimes additional changes follow.
But it is a way to do it and people are used to do it.

I'm thinking more and more about it and I think the best solution is to 
keep svn as the central repo and do a git svn clone from there, so I 
have the advantage of the existing infrastructure and will get the nice 
features from git.

Matthias

-- 
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook

On Tue, Jun 1, 2010 at 01:51, Matthias Fechner [off-list ref] wrote:

I'm thinking more and more about it and I think the best solution is to keep
svn as the central repo and do a git svn clone from there, so I have the
advantage of the existing infrastructure and will get the nice features from
git.

That's probably a good way to get people started with git.

However, git hooks SEEM like they should be enough for your purposes.

For permissions, see contrib/hooks/update-paranoid:

  http://git.kernel.org/?p=git/git.git;h=d18b317b2f018d1d1a5a9677a7bdaf8956d65186

and for emails, see see contrib/hooks/post-receive-email:

  http://git.kernel.org/?p=git/git.git;h=30ae63d74da065a31cced0b161708680f39c04c0

(Sorry if gmail mangles those urls).

Sincerely,
Michael Witten