I haven’t used Git (yet?), but I’ve been doing some reading and I still don’t quite understand the infatuation. Don’t get me wrong, it looks like there are some nice features, but at what cost?

The key difference between the two systems seems to be the model itself. Where Subversion offers a centralized model, Git provides a decentralized model. At the risk of over simplification, this means that Git offers each developer their very own, fully autonomous copy of the entire repository. With Subversion, each developer has their own working copy, but commits changes to a single, central repository.

The arguments in favor of the decentralized approach, as I understand them, include:

Speed

Okay, I like speed. Since each developer has a local copy of the entire repository, fundamental actions like diff, commit, etc. are all local. That’s always going to be faster. Fast is good.

That said, server interaction with Subversion isn’t exactly excessive. Developers work in local working directories and only interact with the server in short bursts. I’ve never found myself thinking, “Great Scott, this is unbearably slow.” For me, at least, this seems like a fix for something that isn’t broken.

Smaller Space Requirement

A Subversion working directory contains two copies of the entire code base. One that is actually being worked on and another tucked away in the .svn directory. I remember reading somewhere that the Mozilla repository required ~12Gb of storage in Subversion and ~420Mb in Git.

This is a substantial difference, to be sure, but there’s a phrase that everyone in technology hears on a daily basis: storage is cheap. That can’t be a compelling argument for one problem and not for another, so I don’t think this difference is one that’s going to precipitate a switch all by itself.

Line Ending Conversion

This is an important factor for mixed environment teams. Evidently early versions of Git made no changes and more recent version handle the conversion automatically. That decisioning is manual with Subversion, but is spectacularly easy to do by making a simple change to ~/.subversion/config for each file extension impacted to specify the line ending desired:

*.sh = svn:eol-style=LF;

Other Concerns

In addition to the fact that none of the arguments presented in favor of Git are particularly compelling to me, at least not the way I understand them, I have a few other concerns about the decentralized model. Actually, they probably all roll up to a single concern – accountability.

Every project I’ve worked on requires some level of immediate or semi-immediate accountability. A project manager who needs to ensure that an appropriate amount of progress has been made against the project plan, a boss who needs to spot review code or maybe a continuous integration process that needs regular repository updates so that its not just rebuilding the same old thing.

It seems like the decentralization of the repository would hamper those efforts. Sure, it can be done, but it would have to be done with process.

I also wonder if, in a team environment, having too many people doing too much of their own thing for intervals that stretch too long would make effective merges all but impossible. It seems like it would.

Am I missing something? Are there additional benefits? Is there anything else I haven’t even mentioned that I should be considering? I’d love to hear from other source control users who have moved to Git from Subversion.

From: http://robwilkerson.org/2008/04/05/subversion-or-git/

相关文章

• 浅谈FreeBSD与OpenBSD (0)
• 解决：Can’t open file ‘/root/.subversion/servers’: Permission denied错误 (0)
• Path-Based Authorization by mod_authz_svn (0)

相关文章

• 几个PHP关于URL和eMail分析方面的类 (0)
• Subversion or Git (0)
• Path-Based Authorization by mod_authz_svn (0)
• Nginx中PHP+FastCGI配置技巧 (0)

Both servers use a common file format to describe these path-based access rules. In the case of Apache, one needs to load the mod_authz_svn module and then add the AuthzSVNAccessFile directive (within the httpd.conf file) pointing to your own rules file. (For a full explanation, see the section called “Per-directory access control”.) If you’re using svnserve, you need to make the authz-db variable (within svnserve.conf) point to your rules file.

Once your server knows where to find your rules file, it’s time to define the rules.

The syntax of the file is the same familiar one used by svnserve.conf and the runtime configuration files. Lines that start with a hash (#) are ignored. In its simplest form, each section names a repository and path within it, as well as the authenticated usernames are the option names within each section. The value of each option describes the user’s level of access to the repository path: either r (read-only) or rw (read/write). If the user is not mentioned at all, no access is allowed.

To be more specific: the value of the section names is either of the form [repos-name:path] or of the form [path]. If you’re using the SVNParentPath directive, it’s important to specify the repository names in your sections. If you omit them, a section such as [/some/dir] will match the path /some/dir in every repository. If you’re using the SVNPath directive, however, it’s fine to only define paths in your sections—after all, there’s only one repository.

[calc:/branches/calc/bug-142]
harry = rw
sally = r

In this first example, the user harry has full read and write access on the /branches/calc/bug-142 directory in the calc repository, but the user sally has read-only access. Any other users are blocked from accessing this directory.

Of course, permissions are inherited from parent to child directory. That means we can specify a subdirectory with a different access policy for Sally:

[calc:/branches/calc/bug-142]
harry = rw
sally = r

# give sally write access only to the 'testing' subdir
[calc:/branches/calc/bug-142/testing]
sally = rw

Now Sally can write to the testing subdirectory of the branch, but can still only read other parts. Harry, meanwhile, continues to have complete read/write access to the whole branch.

It’s also possible to explicitly deny permission to someone via inheritance rules, by setting the username variable to nothing:

[calc:/branches/calc/bug-142]
harry = rw
sally = r

[calc:/branches/calc/bug-142/secret]
harry =

In this example, Harry has read/write access to the entire bug-142 tree, but has absolutely no access at all to the secret subdirectory within it.

	Tip
	The thing to remember is that the most specific path always matches first. The server tries to match the path itself, and then the parent of the path, then the parent of that, and so on. The net effect is that mentioning a specific path in the access file will always override any permissions inherited from parent directories.

By default, nobody has any access to the repository at all. That means that if you’re starting with an empty file, you’ll probably want to give at least read permission to all users at the root of the repository. You can do this by using the asterisk variable (*), which means “all users”:

[/]
* = r

This is a common setup; notice that no repository name is mentioned in the section name. This makes all repositories world-readable to all users. Once all users have read access to the repositories, you can give explicit rw permission to certain users on specific subdirectories within specific repositories.

The asterisk variable (*) is also worth special mention because it’s the only pattern that matches an anonymous user. If you’ve configured your server block to allow a mixture of anonymous and authenticated access, all users start out accessing anonymously. The server looks for a * value defined for the path being accessed; if it can’t find one, it demands real authentication from the client.

The access file also allows you to define whole groups of users, much like the Unix /etc/group file:

[groups]
calc-developers = harry, sally, joe
paint-developers = frank, sally, jane
everyone = harry, sally, joe, frank, sally, jane

Groups can be granted access control just like users. Distinguish them with an “at” (@) prefix:

[calc:/projects/calc]
@calc-developers = rw

[paint:/projects/paint]
jane = r
@paint-developers = rw

Another important fact is that the first matching rule is the one which gets applied to a user. In the prior example, even though Jane is a member of the paint-developers group (which has read/write access), the jane = r rule will be discovered and matched before the group rule, thus denying Jane write access.

Groups can also be defined to contain other groups:

[groups]
calc-developers = harry, sally, joe
paint-developers = frank, sally, jane
everyone = @calc-developers, @paint-developers

Subversion 1.5 brings another useful feature to the access file syntax: username aliases. Some authentication systems expect and carry relatively short usernames of the sorts we’ve been describing here—harry, sally, joe, and so on. But other authentication systems—such as those which use LDAP stores or SSL client certificates—may carry much more complex usernames. For example, Harry’s username in an LDAP-protected system might be CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com. With usernames like that, the access file can become quite bloated with long or obscure usernames that are easy to mistype. Fortunately, username aliases allow you to have to type the correct complex username only once, in a statement which assigns to it a more easily digestable alias.

[aliases]
harry = CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com
sally = CN=Sally Swatterbug,OU=Engineers,DC=red-bean,DC=com
joe = CN=Gerald I. Joseph,OU=Engineers,DC=red-bean,DC=com
…

Once you’ve defined a set of aliases, you can refer to the users elsewhere in the access file via their aliases in all the same places you could have instead used their actual usernames. Simply prepend an ampersand to the alias to distinguish it from a regular username:

[groups]
calc-developers = &harry, &sally, &joe
paint-developers = &frank, &sally, &jane
everyone = @calc-developers, @paint-developers

You might also choose to use aliases if your users’ usernames change frequently. Doing so allows you to need to update only the aliases table when these username changes occur, instead of doing global-search-and-replace operations on the whole access file.

相关文章

• Subversion or Git (0)
• 解决：Can’t open file ‘/root/.subversion/servers’: Permission denied错误 (0)