On Sat, May 18, 2013 at 1:42 PM, Zé <jose.passes_at_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
lesmikesell_at_gmail.com
Received on 2013-05-20 05:44:53 CEST