Post by Stefan SperlingPost by Bo BerglundIt seems like in SVN there must be separate repository folders for
tags, branches and trunk below each project.
To me this implies that svn is only able to do these operations at the
very top of a project tree, is that really so?
I am coming from CVS(NT) and it was always possible to do the tagging
and branching for *anything* inside a project tree. For example a
subtree could be branced and tagged independently from the main
project.
Is this not possible in SVN?
If so, how can I convert my CVS repository to SVN correctly, while
preserving these properties?
We have used this on many places, for example branching out only a
single file or two in a directory while leaving the other files on
TRUNK.
Then at a later time when all is checked we merged the changes back
into TRUNK.
Is this not possible in svn?
Yes it is.
You could either branch the direct parent folder of the file,
or you could create a new directory somewhere, and copy a file
into this new directory to create a branch of this file.
1) There is *no* cost associated with branching the entire tree in SVN.
Stefan, there is a *small* cost. It adds a logged "copy" action on the
Subversion server. And if you ever try to check out all of the
Subversion repository or of the "branches" subdirectory, for whatever
reason, the bulk accumulates. It's why I prune branches regularly.
I agree that there is not noticeably more system cost on the
Subversion server than copying a much smaller directory or even a
single file to a new branch.
Post by Stefan Sperling2) There is *huge* cost for doing the same in CVSNT. And that is the main
reason why your workflow in CVSNT is structured the way it is.
So take a step back and try simply creating *all* your branches at
project-root level. My expectation is that you will not regret it.
Checking out or working with a full source tree rather than a much
smaller working copy, or a working copy of a branch, with only a few
components can be far more burdensome, and vulnerable to merge issues,
than working with a full source tree. It's not just CVS that suffers
from such a burden. And if the source tree involved is large,
especially with a *lot* of small files, it can eventually be quite
burdensome to check out. It's especially burdensome to check out on
Windows boxes writting to CIFS network shares. It used to be *much
worse*, Subversion has much improved that. over the years, I've
certainly noted the improvements. But it's still not "free" to
maintain
It's also true that one can just create an entire new branch on the
Subversion server, cheaply, and check out only the relevant
subdirectory. That can work well, but it can take a bit more education
to get people used to to that. And it can be a bit more awkward to
decide when to delete the obsolete old branch: an "svn diff" between
that branch and the master will show all the other differences that
have never been merged, making decisions *much* harder.
Many source of complex projects wind up with smaller components
embedded in the master source tree: it can be helpful to be able to
checkout *just* that component, or branch a copy of just that, to do
some focused work.
Post by Stefan SperlingGenerally, switching version control tools will ultimately always affect
the development process, there is now way around it. It's better to embrace
the advantages and best practices the new tool offers, rather than trying
to shoe-horn existing workflows into the new tool at all costs.
Stefan, even if I disagree about the usefulness of some workflows
you've mentioned, I agree *completely* that now is a very good time to
look at workflow. People will have new tools available, such as
TortoiseSVN. The time spent to educate users, and come to agreement
about workflow, can pay for itself confusion and conflicts avoided
very, very quickly.