Take the 2-minute tour ×

I have a project with some part of the code that are public and other that are not.

I have the complete project versioned in my entreprise in folder E, and a specific folder P where I put the public part. I thought it was a good idea to put hard-links in folder P of the public files in the folder E.

So that, the usual workflow should be to work on the enterprise versioned folder E, and once in a while go to folder P to commit the public files. (note that if I work 'alone', it works great)

The problem is that when I do some merging/pulling/rebasing of the files in folder E, it replaces the files -> thus changing their inode -> thus the files hard-linked in folder P do not get updated!

So my question is: is there a version control system which authorizes an option not to change inode of files when merging/pulling/rebasing?

I work with git (or git-svn), but I would agree to switch for this convenient option.



PS: I've seen this question (Git and hard links), but here I would like to take advantages of hard links to work more efficiently.

share|improve this question
add comment

1 Answer

My suggestion is to use symlinks; they don't depend upon the inode, and I know they can be versioned in Subversion (and I would expect git). Versioning hardlinks would be very difficult, since it's plausible - albeit a very bad idea - that part of your working copy could cross filesystem boundaries.

share|improve this answer
Hardlinks cannot cross filesystem boundaries. Only Softlinks can. –  Turbo J May 31 '11 at 23:36
Yes I was doing this but if decide to move the path of internal folder, it gets messed up. (And in my case, the limit of hardlinks on a single partition is not a problem). –  Louis Jun 1 '11 at 7:23
You can use relative symlinks, so they won't depend on the location of the tree. :) –  dannysauer Jun 1 '11 at 15:04
@TurboJ - yup, that's why it's unlikely that a VCS will support hardlinks in the revisioned tree; the working copy of a repository could conceivable cross filesystem boundaries, which would make hardlinks nearly impossible to implement as hardlinks. Because any VCS will be assuming that hardlinks aren't supported, it's unlikely that a VCS will have a checkout mode which respects hardlinks in the tree; it'll [rightly] assume that there are no unsupported files in a working copy. –  dannysauer Jun 1 '11 at 15:27
add comment

Your Answer


