On Sat, May 18, 2013 at 1:42 PM, Zé <jose.pas...@gmx.com> wrote: > >> Besides >> that, from my understanding filesystems do provide something which >> could be argued as support for branches and tags because branches are >> simply just work on something based on something other, which is >> implemented as copying files and directories, and tags are something >> which isn't as worked on as on branches, but is based on something >> other, too, and may easily be implemented using copying things around >> again and simply don't touch it anymore or e.g. using snapshots, which >> would better guarantee an unchanged content. > > > That's essentially what subversion does, as the only thing it actually does > is track revisions made in a specific directory.
What do you mean by 'specific directory' here? It tracks the history of anything that has a previous version or a source for a copy/move. That is, you can move or copy any file or directory anywhere else and be able to track back through its history. And that is somewhat at odds with tracking merge history which may not happen on the same boundaries. > It works very well for a > wide range of applications, in some cases better than other SCM systems, but > the lack of support for branches does represent a a shortcoming. I suppose theoretically you could use some namespace tricks to branch the entire repository to get the all-or-nothing effect you seem to want without mapping it into subdirectories, but we have many separate projects in one repository. 99% of what full-repo branching would have to track would never be useful. It only makes sense to us to branch at the project level - which meshes with the file system mapping. -- Les Mikesell lesmikes...@gmail.com