On Wed, Apr 17, 2019 at 12:56 PM Johnny Billquist <bqt%update.uu.se@localhost> wrote:
Correct. However, with a branch, I can see, by looking at the file, in
the one place it is, what different branches that file exists in.
And what is the benefit of knowing all of the branches where a
particular file exists? Branches are separate development streams, so
why would you care if any other branches have this file? If you really
want to know, you can write a small script that looks for a particular
file in various branches in your repo, but this is rather weird use
case. So how does Git give you this information?
That's the point. By convention you try to solve the problem. The issue
is that this only works as far as that convention is followed, and you
have filename space to search instead of looking at the file to find
what branches and tags you have for it.
That's because this convention works very well. People have been
organizing their work into folders and files for years, it is very
easy to understand. Trying to come up with some other obscure
methodology is a questionable practice.
A branched file can be checked out from different branches, and it stays
in the same place in the file system. A copy do not.
There is a difference between a branch (stored on a server) and a
local copy (stored on your local machine). You can checkout from
whatever branch you like. I never needed to have a mixture of files
checked out from different branches under the same local tree, but if
this is what you want to do, then "svn switch" command would probably
work for you http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.switch.html