Re: What's the best way to make my company migrate to Git?
- From
- Daniele Segato <daniele.bilug@gmail.com>
- Date
- Jun 1, 2010, 16:00 UTC
- Message-ID
- <AANLkTinO_Z-1myhT-0TBIjELiEd4H-NnESs-AjTIpEf9@mail.gmail.com>
- In-Reply-To
- <4C041656.7000008@pileofstuff.org>
On Mon, May 31, 2010 at 10:04 PM, Andrew Sayers <andrew-git@pileofstuff.org> wrote:
Show 15 quoted lines
> On 25/05/10 08:42, Michael J Gruber wrote: >> >> Feel free to contribute to the Git Wiki maybe at >> >> https://git.wiki.kernel.org/index.php/GitDocumentation >> >> in the "User contributed Documentation" section. >> >> Michael >> > > Thanks for the hint - this turned into rather more than just uploading a > PDF, and I've now finished a complete write-up here: > > https://git.wiki.kernel.org/index.php/SvnMigration
That's a great job!
I want to point out some difficulties I encountered switching from Subversion to Git-SVN. I'd like to discuss them here before, eventually, contributing them to that page.
= Empty directories = Git do not track directories, it tracks content. That means you'll not get/commit empty directory in your working tree. Sometimes empty directory may be needed by some fancy script or external software you use with your project (example, ANT).
Developers should be aware of this: if they really need to create an empty directory they can both create it through subversion both create a "dummy" file in the directory and commit it, if that's an option.
= Subversion ignore = You can't control subversion ignores from git-svn. And git-svn do not automatically synchronize with the subversion ignores. The team should be aware of these to avoid issues.
= Local patch = Most subversion user keeps some modified files in their local checkout never committing it remotely. This may be handy for some situation where you want to enable some debug-specific feature or whatever you need. With Git, if the file is remotely tracked (with Subversion you'll say "already committed") you can't keep a file like that: it will prevent you from "pushing" files to the remote repository or checking out other local/remote branches. You'll had to "stash" your patch and re-apply it later.
= local/remote branches = Git-svn branches "track" the remote branches by adding a string in each commit you "git svn dcommit" on subversion repository. You can have many local branches tracking the same remote subversion branch. To start to track a new remote branch you have to "git checkout -b localBranchName remoteBranchName", which is not very user friendly :)
You also can't create new Subversion branches or tags with git-svn, you'll had to use subversion directly for that.
Feel free to correct me or better describe those issue with a better/more friendly english. Feel also free to add to this list.
Regards, Daniele Segato