Once you get comfortable with distributed version control, this probably becomes a habit: whenever you start hacking on something new you create a local repository right away, and only later on you push it to a server (for backup). With Bazaar you can even switch to a centralized workflow (the server becomes a master) at any time (and switch back).
To push a local repository to a server, the bzr command must be installed and on the $PATH of the user.
bzr commit -m 'first commit, added all files'
bzr push bzr+ssh://username@server/home/username/path/to/repos/bzr/project
- If the parent directories don’t exist on the server, then use –create-prefix to create all parents
- To switch to a centralized workflow where your local commits will be automatically pushed to the server do “bzr bind”, and to switch back do “bzr unbind”
To push a local repository to a server, the git command must be installed and on the $PATH of the user.
git add .
git commit -m 'first commit, added all files'
git clone --bare . project.git
rsync -a project.git username@server:path/to/repos/git/project.git
rm -fr project.git
git remote add origin username@server:path/to/repos/git/project.git
The step of pushing to the server is less intuitive in Git compared to Bazaar, but I am still new to Git so there might be a better more elegant way. (Please comment if you know!)
I thought sharing a folder on Linux to Windows machines read-only and without any authentication whatsoever was very simple to do with Samba. And it really is, if you know Samba well 🙂 Which I don’t, so I had some troubles due to incorrect value for the “security” option. The default value in a relatively modern installation is “user”, with other possible values like “share” marked as deprecated in the config file. Because of that small mistake my sanity tests failed with error messages like:
C:>net view \servername
System error 5 has occurred.
The network path was not found.
Logon failure: unknown user name or bad password.
Changing “security = user” to “security = share” was the fix. And it is well explained in “man smb.conf”.
Btw the “testparm -s” command shows settings that override the default values, which can be pretty handy in debugging your setup.
UPDATE: you probably also want samba to start on system boot. In redhat derivatives you can do that with:
chkconfig smb on
Useful links to debug Samba (if you are in a hurry)
A nice series of articles for doing a more sophisticated setup the right way
StatSVN is easy to use and free, and can reveal interesting statistics about the commit history of a Subversion repository.
One gotcha I had with it though is that occasionally it can have totally misleading error messages like this one:
svn log: svn info: XML document structures must start and end within the same entity.
The tool works with an XML file generated by “svn log -v –xml” and a svn checkout directory. Although this error message clearly suggests a broken XML file, it was nonsense in all the cases I’ve seen, and the real cause was problems with the svn checkout directory, for example because of files with “!” or “~” status. After I cleaned up the svn checkout directory, statsvn worked nicely.
Another tool for the same purpose that can be interesting is svnplot (a completely different tool, nothing to do with statsvn).
A few people asked what is the meaning of “svn status” showing files with “!” and “~” and how to clean them up. These are problems in your own working directory, most likely because you are using subversion incorrectly. Files marked with “!” are usually files that were deleted not with “svn rm”. A “svn update” can bring them back.
Directories marked with “~” usually happen if the “.svn” directory disappeared from that directory. One typical example is when people incorrectly add build output folders to their repository, and when they build the project the output folder is recreated, inevitably without the “.svn” control directories. The best solution is to remove the build products from the repository and do a clean checkout.
In general, the strange errors with svnstat mentioned in the post should not happen if you run statsvn right after a “svn checkout”.
If you are on a 64-bit windows system, and start bash that’s included with git from a DOS command prompt and experience fork errors like this:
C:Program FilesGitbinbash.exe: *** fork: can't reserve memory for stack 0x490000 - 0x
690000, Win32 error 0
0 [main] bash 1612 sync_with_child: child 4896(0x328) died before initiali
zation with status code 0x1
216 [main] bash 1612 sync_with_child: *** child state waiting for longjmp
bash: fork: Resource temporarily unavailable
… a possible cause can be that your DOS command prompt is the 32-bit version (the default when running cmd with w+r) when you need in fact the 64-bit version. The fix:
c:\windows\syswow64\cmd.exe /c bash
Sometimes you start to work on a new project in git, and sometimes you might have to push it to a Subversion repository. Luckily you can do that, and not just in the dumb way of a single export with no history, but with preserving the history by replaying each of your commits in git to Subversion.
1. Create the target location inside the Subversion repository
svn mkdir https://reposerver/path/to/repo/path/to/project
2. Edit your git repository configuration to make the connection with git-svn
url = https://reposerver/path/to/repo/path/to/project
fetch = :refs/remotes/git-svn
3. Import the empty Subversion history
git svn fetch
4. Replay your commits on top of the empty Subversion history
git rebase remotes/git-svn
5. Push the commits to Subversion
git svn dcommit