5

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?

Community
  • 1
  • 1
Joseph
  • 117,725
  • 30
  • 181
  • 234
  • 1
    have you considered git-svn http://www.kernel.org/pub/software/scm/git/docs/git-svn.html it can handle subversion<->git operations without any "symlink the the file on one repo to the other" stuff. – Sergei Nikulov Sep 24 '12 at 09:41
  • here is example of simple git svn workflow http://andy.delcambre.com/2008/03/04/git-svn-workflow.html – Sergei Nikulov Sep 24 '12 at 09:44
  • [bzr-svn](http://doc.bazaar.canonical.com/beta/en/user-guide/svn_plugin.html) might be another good choice too. Subversion will do nearly the same as Git for symlinks. It represents it as a special file internally, and will create the link when you checkout. The target doesn't have to exist though--just like Git. On Windows, where symlinks don't exist, Subversion will create a `.lnk` file pointing to the target directory. `.lnk` files are Explorer Link files. – John Szakmeister Sep 24 '12 at 10:03
  • 2
    @jszakmeister I think there is not important how to source control handles symlinks. The main issue how to keep in sync two repos. And it seems to me the whole idea is wrong - "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." – Sergei Nikulov Sep 24 '12 at 10:16
  • 1
    @Sergey Sorry, I wasn't trying to answer his question, but provide more insight into how Subversion handles symlinks for background knowledge. I agree, symlinks here is a broken concept. Something like git-svn, bzr-svn, or hgsubversion might be better fits. Though, depending on the features used in Subversion, might be problematic too (externals and the lack of first class branches being the most troublesome). – John Szakmeister Sep 24 '12 at 10:22

2 Answers2

2

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/)
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
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.

Sergei Nikulov
  • 5,029
  • 23
  • 36