Keeping two files in sync between two repositories - symbolic links? or another way?

Question

In a school project we have, the VCS in use is SVN.

Constraints:

• Our professor does not want to commit non-working code into the central repository.

• I will be working on the code on the go. I code on a laptop, a desktop and a PC in the office during different times of the day (Being productive I guess)

• We are not allowed to branch

I was thinking that I would store the file I'm working on on another repository (and maybe GIT) to move around and avoid committing "dead code" on the main repository. After that, to avoid copy pasting stuff between the two repos, I'd symlink the the file on one repo to the other. And so, I'd be committing the file endlessly on one repo, and then when done, I'd commit on the other.

However, I don't know what's the behavior of VCS with regards to symlinks.

I have read an answer here in StackOverflow that GIT stores a symlink as a file and when retrieving it, it returns it to a symlink regardless if the target does or does not exist - this is not good. I might be getting "dead files" instead.

I also have read this documentation for SVN and does not tell anything about what comes out after retrieving a symlink.

And so, what should I do to sync two repositories with the same file? Should I go for symlinks or is there another way?

Answer 1

Intro:

"No dead code" AND "no branches" is bad and ugly development policy, policy leading to a huge, non-manageable commits as result (most times)

1. Forgot about pure symlink, use native tools and methods
2. (some) External sources can be linked to Subversion repo using Subversion externals
3. Mobile development is (almost) irrelevant question to first part of problem: use any (D)VCS of choice, which can be lately bridged to Subversion (Mercurial, Git, Bazaar, Fossil-SCM /over git-export/)

Answer 2

Here is my proposal:

1. git svn clone < url to professor repo >
2. after step 1 you have your local copy of subversion repo
3. git branch < branch name > - don't worry your professor will not see this branch
4. work on your branch and commit whatever you want until you're done - all works and tests are passed - it's time to give your code to professor
5. git checkout master
6. git svn rebase - will pick latest changes from svn mainline
7. git merge < your branch name > - you can use --squash option if professor like to see single commit
8. git svn dcommit - will publish your changes on mainline

HTH.