On Thu, Aug 28, 2014 at 3:28 AM, Zé <jose.passes_at_gmx.com> 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.
And yet, the there was the problem of accessing through the file
system under different user ids.
>> 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.
On the contrary, everyone arguing for using a server feels that
filesystem protections are inadequate. If you don't care about that,
there is nothing inherent to subversion that makes file:// access a
problem.
> 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..."
For someone already using apache, that's trivial - just module that
can co-exist with a myriad of others. And if you aren't using
apache, svnserve is easy. And all are packaged such that anyone
familiar with the the operating system or installing any program can
do it easily. More to the point, in any organization, only one person
has to set up the server and a large number of people only need the
client.
> Do you believe this is acceptable? Even plain old rsync -a is a far better
> alternative than this.
If you just want a backup copies of a few versions taken at random
points in time, there are lots of better solutions (I like backuppc
myself) but they all involve getting those copies onto a different
filesystem and stored such that the same hardware or software error or
user command that destroys the original won't take the backups with
it.
> 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?
Using file:// is no worse than any other mechanism that stores the
data so any user can corrupt it directly - but no better either. If
that's what you want, subversion will let you do it. However, it is
designed to do better and let you put your files under central control
with better management than the local filesystem can provide. You
just have to decide what you want from it. And you are right that
some of the version control systems designed for distributed use might
be better suited to having multiple copies sitting around in different
places in different states like you have to do if you just have files
with some backup copies somewhere - and you are willing to lose
versions if you have a problem with your local copy. Subversion's
strength is in keeping one authoritative copy in a place where it can
be managed better than client's own filesystems.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2014-08-29 15:09:47 CEST