I am not sure what exactly the original poster is referring to but the main feature of svn that git can’t do is treat each directory as its own repository.
So if you make a repository like:
src/
libs/
my_debug_lib/
my_core_lib/
etc/
In svn someone can checkout libs/my_debug_lib and treat that as its own repository (ignoring the directories above that level).
A secondary thing is “externals”. With svn you can add another repository as a directory. Git has submodules, but it is not the same and more cumbersome (for example each time the remote repository is updated, you need to perform a local commit to bring your reference up to date with the remote).
> Git has submodules, but it is not the same and more cumbersome (for example each time the remote repository is updated, you need to perform a local commit to bring your reference up to date with the remote).
It's simply not revision controlled if two different checkouts of the same version produce different source trees.
externals might be convenient for moving targets, but that's entirely wrong behavior for a revision control system.
Comments
Subversion has features Git doesn't and can't support.
Is there a good list of these features somewhere?
I am not sure what exactly the original poster is referring to but the main feature of svn that git can’t do is treat each directory as its own repository.
So if you make a repository like:
In svn someone can checkout libs/my_debug_lib and treat that as its own repository (ignoring the directories above that level).A secondary thing is “externals”. With svn you can add another repository as a directory. Git has submodules, but it is not the same and more cumbersome (for example each time the remote repository is updated, you need to perform a local commit to bring your reference up to date with the remote).
I guess a third svn feature is file properties.
> Git has submodules, but it is not the same and more cumbersome (for example each time the remote repository is updated, you need to perform a local commit to bring your reference up to date with the remote).
It's simply not revision controlled if two different checkouts of the same version produce different source trees.
externals might be convenient for moving targets, but that's entirely wrong behavior for a revision control system.
The can't support was directed at file locking, which is mainly useful for binary files that can't be merged.
Do you mean "Git has features Subversion doesn't and can't support"? :)