On Wed, Dec 6, 2017 at 5:33 AM, Stefan Sperling <stsp_at_apache.org> wrote:
> On Wed, Dec 06, 2017 at 08:44:42AM +0100, Bo Berglund wrote:
>> It 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.
>
> However, I would suggest you reconsider your workflow, because:
>
> 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.
> 2) 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.
> Generally, 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.
Received on 2017-12-06 13:23:25 CET