Am Mi, 12 Aug 2009 schrieb Ryan Raasch: > > Would be cool for you to elaborate! I have been using git for over a > year in an subversion environment, and it seems you have found a > sweet spot between the two.
Well, it's mostly a matter of finding the right balance between
the centralized aproach of subversion and the bazaar model of git.
Corporate workflow has pretty much different requirements than
the classic open source development.
For example, not everything can be open to _anyone_ at _any_ time,
even if it will be fully open sourced in the end. There are contracts,
non disclosure agreements, test results, orders, etc. And things
generally get more complicated, if any bigger company is in the loop ;-)
But this wasn't the main concern with git in corporate workflow.
The main concern was daily backup (or, if you will: RESTORE). With
subversion, you were forced to submit as early as possible. Otherwise
your working-copy would be a mess sooner or later. But w/ git, this
isn't a problem at all. Need a new branch? ...klicka,chacka,klack...
Unfortunately, sooner or later all these branches are located
anywhere (on laptops, workstations, development servers), but not
necessarily on the centralized server infrastructure - where regular
backup and restore can be handled without woe.
The main reason is, that even OSS hackers tend to keep some of their
work "private", until it has reached a certain amount of stability.
But since git repositories are not just "working copies", you can't
as easily check for unsubmitted changes as it was before with
subversion.
The current setup is like this:
- along with the centralized subversion servers,
there are now a series of centralized git
repositories. Some of them are open for public,
some can only be accessed by selected developers
and others are completely private.
- depending on the type of repository, these
access paths are possible:
read only:
git://<server>/<group>[/<app_group>]/<repo>
ssh://<server>/<group>[/<app_group>]/<repo>
http://<server>/<group>[/<app_group>]/<repo>
https://<server>/<group>[/<app_group>]/<repo>
read/write:
ssh://<server>/<group>[/<app_group>]/<repo>
https://<server>/<group>[/<app_group>]/<repo> <- very slow
Since we wanted to keep the URLs static,
<group> is also a bindmount in /
(otherwise you'd get different urls for
ssh and git or http)
e.g:
git://git.pengutronix.de/git/ptxdist
http://git.pengutronix.de/git/ptxdist
ssh://git.pengutronix.de/git/ptxdist
http://git.pengutronix.de/git/tools/microcom
ssh://git.pengutronix.de/git/tools/microcom
- For the r/w repositories, access is controlled
by the unix access rights of the repository
group directory and the repository itself.
- For the more public repositories with
r/o access, things get complicated. git
daemon, ssh and apache have their own idea
of access control. So we decided to
differenciate between fully public servers
like http://git.pengutronix.de/, where
only write access (ssh) is controlled and
everything else is open. So, all protocols
are possible here without any hassle.
To enable shared access, the corresponding
directory for the repository has to be g+s
and the "sharedrepository = 1" has to be set
in the git repo config. Enabling the
"denyNonFastforwards = true" is also
advisable.
e.g.
drwxrwsr-x 8 pengutronix ptx 4096 7. Jul 14:44 ptxdist
---------------------- snip -------------------------
[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedrepository = 1
logallrefupdates = true
[receive]
denyNonFastforwards = true
[hooks]
mailinglist = ptxdist-com...@pengutronix.de
emailprefix = [git:ptxdist]
---------------------- snip -------------------------
- For customer repositories, the only access
path is ssh _OR_ https. This way, you have
to do access controll only one way. Each
customers can get a private server, if needed.
Since https has proven to be very slow,
ssh is generally the way to go (and it can
be integrated nicely with the existing key
management.
- For private repositories, only ssh access
is possible. Unix access rules apply. No
exceptions, no problems :o)
- All repositories can be equipped with a
generic send-mail-on-commit hook, as we
used to handle subversion repositories.
There are commit-mailinglists for all
types of repository.
We are still in the process of testing and optimizing
the setup - most issues can be addressed by policy,
some problems like ipv6 integration needed little
workarounds or tweaks. We will prepare a paper
about the established workflow, as soon as it has
settled a bit.
Greetings,
Bjørn
--
Pengutronix e.K. | Bjørn Bürger |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5002 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
signature.asc
Description: Digital signature
-- ptxdist mailing list ptxdist@pengutronix.de
