On Wed, Apr 17, 2019 at 12:56 PM Johnny Billquist <b...@update.uu.se> 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