On Sat, Sep 24, 2011 at 2:19 PM, Andreas Krey <a.krey_at_gmx.de> wrote:
> ...
>> If you want tags to be immutable, you know how to make them that way.
>
> I want them mostly immutable, that is, not accidentally, but with -f
> (which is pretty much the way any other VCS is doing it).
>
> As far as I can see there is no way of making subversion do that.
Perhaps not with a command line option, but the pre-commit hook can
examine the commit message for some "I know what I'm doing' token to
allow an otherwise blocked action. Or if the point of the commit is
to add some build artifacts back to the matching tag you can permit
that based on the filenames.
>> On the other hand, a path and revision number are always immutable and
>> all you really need a tag for is to have a (slightly) more
>> human-friendly name - which you are probably going to cut&paste
>> whether it is short and friendly or not.
>
> 'ipv6' or 'fdpass' aren't really requiring c&p. On the other hand,
> switching branches in svn usually requires 'svn info' and then
> c&p'ing the path together out of the old path and the replaced
> branch/tag name. Heck, you need to do that even for *finding out*
> which branches exist.
svn ls repo/project/branches ?
> And 'module-v1.2.4' is not just 'slighly' more human-readable
> than 'trunk_at_21354', the latter explicitly *not* conveying
> the relevant information.
Without some additional documentation regarding the project
conventions, both convey no information about the content. Not
arguing against conventions or friendly names, of course - just
pointing out that tracking the path/rev is sufficient unless you tag
from working copies which is somewhat dangerous anyway since it can
introduce changes with no other history.
> ...
>> > 'They don't have the repo' is just an illusion.
>>
>> But you can control access to the svn repository at the path level and
>> you can't svnsync if you don't have read access. How do you give a
>> person or group access to only a portion of a git repo?
>
> You don't. You don't put everything into a single git repo as you do
> with svn, but only what you would branch/tag separately in svn. And
> providing repo-wise access control is no problem.
How do you make that accommodate the practice of having a different
group (perhaps outside contractors) work on a component (only) within
an existing project? Even a single project often outlives its
original team and permissioning concepts.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2011-09-25 18:51:53 CEST