Can SVN only branch and tag at the highest project level?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Can SVN only branch and tag at the highest project level?

Bo Berglund
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?

--
Bo Berglund
Developer in Sweden

Reply | Threaded
Open this post in threaded view
|

RE: Can SVN only branch and tag at the highest project level?

Cooke, Mark-2
> -----Original Message-----
> From: Bo Berglund [mailto:[hidden email]]
> Sent: 06 December 2017 07:45
>
> 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?
>
> --
> Bo Berglund
> Developer in Sweden

No doubt others will answer more eloquently but svn imposes no restrictions on the meaning of any folder, the trunk/tags/branch triumvirate is just a convention.  You can read the online book for more information:

http://svnbook.red-bean.com/nightly/en/svn.tour.importing.html#svn.tour.importing.layout

~ Mark C

Reply | Threaded
Open this post in threaded view
|

Re: Can SVN only branch and tag at the highest project level?

Stefan Sperling-9
In reply to this post by Bo Berglund
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.

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.

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.
Reply | Threaded
Open this post in threaded view
|

Re: Can SVN only branch and tag at the highest project level?

Bo Berglund
On Wed, 6 Dec 2017 11:33:30 +0100, Stefan Sperling <[hidden email]>
wrote:

>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.

OK, I see. I am now on page 19 of the SVN-Book (400+ pages...) so I am
not really yet into it.

But we need to do something because we are running CVSNT on a very old
cvs.exe service and had to shoehorn it into a new Windows server.
After researching alternatives I found that only SVN is really close
enough to make it possible to migrate.


--
Bo Berglund
Developer in Sweden

Reply | Threaded
Open this post in threaded view
|

Re: Can SVN only branch and tag at the highest project level?

Nico Kadel-Garcia-2
In reply to this post by Stefan Sperling-9
On Wed, Dec 6, 2017 at 5:33 AM, Stefan Sperling <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Can SVN only branch and tag at the highest project level?

Stefan Sperling-9
On Wed, Dec 06, 2017 at 07:23:21AM -0500, Nico Kadel-Garcia wrote:
> 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.

And there's "svn switch", which reduces the initial checkout to a one
time cost because it only transmits deltas.

It works well even if local changes are present in the working copy.

My preferred idiom for using a branch is:

Modify some files in a full checkout of trunk.
"Oh, this should be on a branch!"
$ svn cp ^/trunk ^/branches/newbranch
$ svn switch ^/branches/newwbranch
$ svn commit

Done. And a trunk working copy is just another switch away.