git-svn and git use the same functionality locally when running. The difference occurs when sending or receiving changes from a remote repository.
Push vs. dcommit.
Why does git-svn need this separate dcommit command?
Because the Subversion repository behaves differently than the remote Git: SVN repository always tries to merge incoming changes at the directory level. If one modifies a file that was changed at the same time by another user, SVN rejects the incoming changes with an outdated error. Otherwise, commit / dcommit .
In contrast, Git push returns an obsolete error when one modifies the same branch / tag, regardless of which files were affected.
As a result, git-svn dcommit should make sure that the version just installed matches the expected version (some directories can be automatically merged during dcommit ). This means that git-svn always pulls / pulls back the changes that it just posted to the SVN repository.
The file is ignored.
When someone ignores certain files in the working tree and commits this modification, there is no way to send this modification using git-svn dcommit . Thus, there is no way to share ignoring other users of the SVN repository.
Git.
Both Subversion and Git have specific metadata associated with files and directories. Like .gitignore there is no way to share .gitattributes with colleagues.
Merge commit.
Finally, when you try to make dcommit merge, it is likely that some commits will not be sent to the SVN repository at all. This happens when all the merged branch commits have not yet been pushed to the SVN repository.
Most of these git-svn problems are difficult or even impossible to fix. You might consider SubGit , a server-side alternative to git-svn that fixes most of them.
See the SubGit and SubGit vs. Documentation documentation for more details. git-svn .
vadishev
source share