On Thu, Aug 28, 2014 at 4:28 AM, Zé <jose.passes_at_gmx.com> wrote:
> On 08/27/2014 05:58 PM, Bob Archer wrote:
>>>
>>> -----Original Message----- And I hate to repeat myself, but I'll
>>> repeat for the third time this question: if file:// is not intended
>>> to be used, then what are the available options for those who need
>>> a version control system and can't set up a server?
>>>
>>> Zé
>>
>>
>> Does the file server support SSH?
>
>
> There is no file server. This discussion is about local repositories on a
> local system (a workstation) managed and accessed by a single user.
Bob was referring to the host with the SVN repository on it. Calling
it a "file server" was confusing, but accidental. Stay calm, please.
It's also not accessed by a "single user". In UNIX permission terms,
it's being accessed by your personal account, one "user", and as you
described it, "root", another "user".
>> Be definition you have a server since the files are on it. Just run
>> the svnserve deamon on it even if it is your workstation.
>
> This is the problem. I doubt anyone who claims this is a reasonable
> approach has even considered the problem and thought about how the solution
> is simply unacceptable.
And I'll tried to explain that you can use 'svn+ssh' to channel the
access to a designated user, whether your own account or a designated
'svn'' user. By controlling the relevant SSH keys, you can set it up
to not require passwords for your SSH keys, and to have the SSH key
enforce svn-only access for that particular application.
Most of us already have an SSH daemon running, and it doesn't need a
background svnserve daemon running. The svnserve runs only when
started by, and is open only during, that particular SSH session to
that particular SSH connection.
The alternative, which will usually work, is to set up group
memberships and use 'sgid' permissions judiciously in the Subversion
repository. Such permissions are not replicated by 'svnsync' or other
back and restoration approaches, so it's extra work.
Mind you, for local config file management and no need for
centralizing the content elsewhere, I tend to use RCS for individual
files (mostly because I'm old, and it's familiar.), or git for
directories. That way the repo is entirely local to the working
directory, and I'm less likely to have the kind of issue you're having
right now.
> For example, picture the scenario where someone tries to pitch subversion to
> a version control newbie to use for such basic tasks such as track changes
> to a file tree present on his file system:
>
> newbie: "this version tracking thing sounds neat. how do I track this
> folder, then?"
>
> svn supporter: "well, you start off by installing Apache and mod_dav_svn on
> your desktop, register a dedicated user account to run the server, and setup
> a subversion server. Don't forget to read these books on the basics behind
> server management, or else you risk getting hit by a myriad of security
> problems..."
Subversion is evolved from CVS. CVS basically had the same issues
about permissions: locall file based access was possible, but could
create permissions issues when multiple users wrote to it directly.
And you're talking about multiple users: your personal account, and
root.
Subversion is better than CVS in every way, for many reasons. And the
svnserve daemon is not Apache, it's built into every published
Subversion distribution I've seen, and I've explained twice now that
svn+ssh is built into the system and doesn't require running a
separate daemon.
> Do you believe this is acceptable? Even plain old rsync -a is a far better
> alternative than this.
Oh, lordie. You're comparing apples and oranges, and getting mad
because you might have to peel the orange to use it. And oh, by the
way? If you feel the need for rsync based backups, do look into
'rsnapshot' as an effective toolkit to manage rsync backups.
> Frankly, this approach makes no sense. It makes much more sense and much
> more efficient to simply abandon subversion and migrate to pretty much any
> version control system. I'm not aware of any other system who forces users
> to install, manage and run servers just to track changes made to a file.
> How is this acceptable?
Then you've never run CVS, Perforce, BitTracker, and half a dozen home
brew systems I'm aware of that were written by CTO's who couldn't
maintain anymore and which I replaced with Subversion.
Whether it's one machine or not, when you want to have the same source
control reository written to by multiple user accounts, a service (not
necessarily an added server!!!) is a well known and well understood
solution.
Received on 2014-08-28 11:00:57 CEST