svn; utilize lazy copies for existing versions (branches) on initial commit.

Question

Hey guys, I'm moving to subversion.

I have 2 different websites based on the same codebase with heavy differences (they differ about 15%). Sites both have >10K files. When I develop something for 'A', I sometimes synch 'B' with changes, or changes may be specific to 'A', or vice versa.

So I think it will be logical to have them as two branches in the same repo, and the trunk may be empty for now.

I know a similar compression will apply for the svn file system anyway, but will it be completely ok if I initially commit these as two branches? Or should I;

• create & commit the default folder structure,
• commit 'A' as the first branch,
• copy 1st branch as 2nd branch
• update the working copy,
• delete the 2nd branch in the working copy,
• copy 'B' site to the 2nd branch in the working copy,
• commit

so the server will know (or not?) unchanged files between branches, and keep them as lazy copies?

Btw, some file dates may differ though they have the same content, as usual.

Answer 1

I think you are on the right track in order to minimize the storage-amount within the SVN.

I'd recommend the following technique:

• commit "A" as a branch in the repo
• remote copy (aka branch) "A" into new branch "B" - A and B are now completely the same
• check out "B" as a new project/folder (outside your "A"-working dir)
• add the changed files into "B" ( I'm pretty sure the modify-date won't count as a diff)
• commit "B"

Good luck!

Answer 2

Did some expirements. Well, turns out SVN always keeps a single copy of a content, whether a file with the same content is commited in the same revision, in a different revision, or is branched from another file. They all reference a hash, and get the content from the first commit.

So, in the means of size, an initial commit with all branches is completely ok, even results in a slightly smaller repo size due to less revisions.

Going with the 'branching' path adds a branch info into the revision. However, it's only useful for human readable reference, and I think will not be important or even meaningful in the initial commit. It can also be written into the commit description if wanted.