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
Signature · 1 line
"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
Quoted 11 lines · Matthias Fechner
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.
Quoted 7 lines
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.
Quoted 7 lines
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.
Am 26.05.10 18:23, schrieb Ævar Arnfjörð Bjarmason:
Quoted 3 lines
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
Signature · 1 line
"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
Quoted 7 lines · Matthias Fechner
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]
Quoted 7 lines
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:
Quoted 4 lines
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
Signature · 1 line
"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
Quoted 11 lines
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).
Quoted 9 lines
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/
Quoted 4 lines · Matthias Fechner
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?
Quoted 2 lines
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:
Quoted 2 lines
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
Signature · 1 line
"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
Quoted 4 lines · Matthias Fechner
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