You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Weintraub <qa...@gmail.com> on 2011/09/22 20:40:23 UTC
Use of svnserve and Dropbox
One of the nice thing about Dropbox is that you can share files
between various users. I will sometimes keep a Subversion repository
on Dropbox, so I can access it on various systems. Right now, it's
just for me to use.
Here's the scenario:
* I have my Dropbox under $HOME/Dropbox.
* I create a Subversion repository on $HOME/Dropbox/svn_repos
* I now share my $HOME/Dropbox/svn_repos folder between my colleagues.
What happens if we all start svnserve on that particular shared folder
in Dropbox? Is there an issue with possible collisions if two or more
people attempt to commit their changes at the same time?
What if we skip the svnserve route and merely use the file://
protocol? Is this any safer?
--
David Weintraub
qazwart@gmail.com
Re: Use of svnserve and Dropbox
Posted by Chris Albertson <al...@gmail.com>.
Sharing the repository and having everyone run their own server
defeats the purpose. Not just with SVN but with any sepup where we
have a server process and a data store the pourpose of the server
mostly is to serialize or control access to the data, maintain locks
and so on.
On Thu, Sep 22, 2011 at 11:40 AM, David Weintraub <qa...@gmail.com> wrote:
> One of the nice thing about Dropbox is that you can share files
> between various users. I will sometimes keep a Subversion repository
> on Dropbox, so I can access it on various systems. Right now, it's
> just for me to use.
>
> Here's the scenario:
>
> * I have my Dropbox under $HOME/Dropbox.
> * I create a Subversion repository on $HOME/Dropbox/svn_repos
> * I now share my $HOME/Dropbox/svn_repos folder between my colleagues.
>
> What happens if we all start svnserve on that particular shared folder
> in Dropbox? Is there an issue with possible collisions if two or more
> people attempt to commit their changes at the same time?
>
> What if we skip the svnserve route and merely use the file://
> protocol? Is this any safer?
>
> --
> David Weintraub
> qazwart@gmail.com
>
--
Chris Albertson
Redondo Beach, California
Re: Use of svnserve and Dropbox
Posted by Andreas Krey <a....@gmx.de>.
On Fri, 23 Sep 2011 09:41:54 +0000, Thorsten Schöning wrote:
...
> I didn't write any commit triggers regarding tags until now, but am
> able to use them.
Except that they behave like branches instead of tags. If you check
out a tag and then commit into it, there will be exactly no warning.
Neither will there be if you accidentally 'create' an existing tag
by doing 'svn cp $someting $dest/tags/tagname' which will not even
move the tag but rather create a new directory within it.
This is all logically sound from the way svn is designed, but it
is not exactly what you expect from tags (like, being immutable
except when using -f).
(Hmm, I should really check whether our commit trigger prevents
removing and recreating an entire /tags directory.)
...
> The simple difference is, that a commit in SVN is enough. With git the
> dev has to commit and the push must be organized somehow, too.
Which is a very mixed blessing. On the one hand side new people
tend to forget the push. On the other hand side it has the big
advantage that you can affort to be wrong in a commit (like,
mistyping the commit message or forgetting to add a file, or
being wrong about how you only commit the property change in
the root but nothing else), and fix that before the push.
And, usually as long as you don't push it you can repair any
commit, not just the last.
Summary: As long as you work on one branch (trunk) and don't care too much
for the quality of the individual commits (as opposed to the resulting
tree), svn CLI is fine and dandy. Working with branches, however, is
cumbersome in a completely unnecessary way. Unfortunately I often find
myself in the latter part due to the kind of work I do.
Andreas
Re: Use of svnserve and Dropbox
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Andreas Krey,
am Freitag, 23. September 2011 um 08:00 schrieben Sie:
> The svn user interface (at least the one that
> is ontopic here, namely the 'svn' CLI) is horrible, mostly due to
> the fact that svn only pretends to have branches and doesn't have
> tags at all. (It replaces them by a convoluted history tracking, and
> by forcing each installation to write commit triggers, respectively.)
I didn't write any commit triggers regarding tags until now, but am
able to use them. I don't see the coherence to a good cli either.
> That is usually not a problem. You just have a central 'blessed' repo, and
> what isn't (pushed) there doesn't officially exist. Just like in an svn
> setting what is not committed does not exist.
The simple difference is, that a commit in SVN is enough. With git the
dev has to commit and the push must be organized somehow, too.
> 'They don't have the repo' is just an illusion.
Agreed.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Use of svnserve and Dropbox
Posted by Andreas Krey <a....@gmx.de>.
On Wed, 28 Sep 2011 10:06:31 +0000, David Brodbeck wrote:
...
> I suspect this is vi vs. Emacs all over again. People who have gotten used
> to the svn user interface (or CVS, for that matter) will find git clumsy;
> people who are used to git will find svn clumsy.
Partly, yes. svn has a tendency to define a base mechanism and let
that shine through, while git rather takes nonorthogonal shortcuts
which look strange but are useful. Example:
svn resolve --accept=$whatever
is more orthogonal while the older
svn resolved
is much simpler to use in the common case.
Likewise, the complete refusal to acknowledge the existence of
tags and branches leads to annoyingly unhelpful commands, like
having to tag and branch with 'svn cp' and explicitly naming
the t/t/b convention every time, or the need to name an explicit
working copy directory name on checkout because 'trunk' is really
not a good name usually.
This philosopy is there in a lot of places, to the extent that I
wonder whether the svn cli was actually intended to be used or
just exists as a reference implementation and to drive users into
GUI usage. TortoiseSVN does take the second-last path component
as the default for the working copy name when the last one is 'trunk',
for instance.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Use of svnserve and Dropbox
Posted by David Brodbeck <br...@uw.edu>.
On Thu, Sep 22, 2011 at 11:00 PM, Andreas Krey <a....@gmx.de> wrote:
> > and Git is just not as user friendly or as polished.
>
> Don't make me rant. The svn user interface (at least the one that
> is ontopic here, namely the 'svn' CLI) is horrible...
I suspect this is vi vs. Emacs all over again. People who have gotten used
to the svn user interface (or CVS, for that matter) will find git clumsy;
people who are used to git will find svn clumsy.
--
David Brodbeck
System Administrator, Linguistics
University of Washington
Re: Use of svnserve and Dropbox
Posted by Les Mikesell <le...@gmail.com>.
On Sat, Sep 24, 2011 at 2:19 PM, Andreas Krey <a....@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@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@gmail.com
Re: Use of svnserve and Dropbox
Posted by Andreas Krey <a....@gmx.de>.
On Fri, 23 Sep 2011 14:59:40 +0000, Les Mikesell 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.
> 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.
And 'module-v1.2.4' is not just 'slighly' more human-readable
than 'trunk@21354', the latter explicitly *not* conveying
the relevant information.
...
> > '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.
Andreas
Re: Use of svnserve and Dropbox
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Sep 23, 2011 at 1:00 AM, Andreas Krey <a....@gmx.de> wrote:
>
> Don't make me rant. The svn user interface (at least the one that
> is ontopic here, namely the 'svn' CLI) is horrible, mostly due to
> the fact that svn only pretends to have branches and doesn't have
> tags at all. (It replaces them by a convoluted history tracking, and
> by forcing each installation to write commit triggers, respectively.)
If you want tags to be immutable, you know how to make them that way.
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.
>> good. If run a development shop building a proprietary trading
>> application for a large financial firm, and a million people have a
>> copy of your repository, that's bad.
>
> For one, the million people still have the current source in their
> sandboxes which is the most valuable part or the repo, and second,
> nothing keeps the bad guy to run svnsync or 'git svn clone' (which
> half of your devs are likely to use anyway) to get a repo copy.
> '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?
--
Les Mikesell
lesmikesell@gmail.com
Re: Use of svnserve and Dropbox
Posted by Andreas Krey <a....@gmx.de>.
On Fri, 23 Sep 2011 01:18:28 +0000, David Weintraub wrote:
...
> I'm not a big fan of Git. Tracking patches and diffs is not the same
> as version control,
The track&diff part is in *addition* to version control proper.
> and Git is just not as user friendly or as polished.
Don't make me rant. The svn user interface (at least the one that
is ontopic here, namely the 'svn' CLI) is horrible, mostly due to
the fact that svn only pretends to have branches and doesn't have
tags at all. (It replaces them by a convoluted history tracking, and
by forcing each installation to write commit triggers, respectively.)
...
> I am still not convinced that Git is good in corporate environments.
> In those places, you want a centralized repository and the control it
> gives you.
That is usually not a problem. You just have a central 'blessed' repo, and
what isn't (pushed) there doesn't officially exist. Just like in an svn
setting what is not committed does not exist. (It gets more interesting
when you don't trust your users, with respect to access control, b/c of
the separation between who pushed and what is the author name in the
commits pushed.)
> good. If run a development shop building a proprietary trading
> application for a large financial firm, and a million people have a
> copy of your repository, that's bad.
For one, the million people still have the current source in their
sandboxes which is the most valuable part or the repo, and second,
nothing keeps the bad guy to run svnsync or 'git svn clone' (which
half of your devs are likely to use anyway) to get a repo copy.
'They don't have the repo' is just an illusion.
Andreas
Re: Use of svnserve and Dropbox
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
David Weintraub wrote on Fri, Sep 23, 2011 at 01:18:28 -0400:
> Thanks for all the replies.
>
> Yeah, I figured this wouldn't be a good idea. There's no way to
> prevent multiple users from simultaneous updates. Even if Subversion
> could allow multiple svnserves hitting the same repository by tracking
> lock files,
Subversion does allow multiple svnserves to serve one repository
concurrently --- for the standard definition of "one", at least.
(which dropbox doesn't meet)
And, FWIW, lock files aren't your only concern. The non-safety of
rsync-style backup is another.
Re: Use of svnserve and Dropbox
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Sep 23, 2011 at 12:18 AM, David Weintraub <qa...@gmail.com> wrote:
>
> Having a publicly available Subversion repository is the best way. The
> problem is what do you do if you don't have that.
VPN's are the usual approach to having access over the internet to
something that isn't public. OpenVPN is fairly simple to set up and
cross-platform.
> For multi-user projects, I've used Git. I keep the main Git repository
> is accessible via Dropbox, and everyone is suppose to be able to pull
> from it, but they're not suppose to push changes directly to the
> Dropbox repository. Instead, they're suppose to email me the patches,
> and I'll push them back to the Dropbox repository.
>
> I'm not a big fan of Git. Tracking patches and diffs is not the same
> as version control, and Git is just not as user friendly or as
> polished.
That's not the way you are supposed to use git. If your dropbox
location had sufficient space, consider how it would work if each user
had his own git clone there so you could pull what you want to merge
from them.
> I am still not convinced that Git is good in corporate environments.
> In those places, you want a centralized repository and the control it
> gives you.
Agreed, but you have to give the users access to the server either
with network connections behind your firewall or VPN access.
--
Les Mikesell
lesmikesell@gmail.com
Re: Use of svnserve and Dropbox
Posted by David Weintraub <qa...@gmail.com>.
Thanks for all the replies.
Yeah, I figured this wouldn't be a good idea. There's no way to
prevent multiple users from simultaneous updates. Even if Subversion
could allow multiple svnserves hitting the same repository by tracking
lock files, you'd still have an issue with Dropbox latency issues.
Dropbox is pretty fast at updating other user's computers, but it
isn't instantaneous.
Having a publicly available Subversion repository is the best way. The
problem is what do you do if you don't have that.
I do keep my personal repository in Dropbox, and I do run separate
svnserve processes on all the machines I use pointing to that
repository.But, I'm not worried about sync collisions. I'm only on one
box at a time.
For multi-user projects, I've used Git. I keep the main Git repository
is accessible via Dropbox, and everyone is suppose to be able to pull
from it, but they're not suppose to push changes directly to the
Dropbox repository. Instead, they're suppose to email me the patches,
and I'll push them back to the Dropbox repository.
I'm not a big fan of Git. Tracking patches and diffs is not the same
as version control, and Git is just not as user friendly or as
polished. However, there are times when having a distributed revision
control system is nice. I can see why many open source projects use
Git.
I am still not convinced that Git is good in corporate environments.
In those places, you want a centralized repository and the control it
gives you. As I told one Git advocate. If you run an open source
project, and a million people have a copy of your repository, that's
good. If run a development shop building a proprietary trading
application for a large financial firm, and a million people have a
copy of your repository, that's bad.
--
David Weintraub
qazwart@gmail.com
Re: Use of svnserve and Dropbox
Posted by Chris Albertson <al...@gmail.com>.
My first impression is that of course this will not work. But let's
be more positive. What would work?
1) Use your SVN server to maintain versions and history and then
checkout a working directory to the dropbox. You can even have
multiple working directories in the dropbox.
2. put your SVN server in the Internet. Run it on any computer you
might have. Old notebooks make good low volume servers. All you need
is a home DSL line and dynamic IP.
Re: Use of svnserve and Dropbox
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ben Smith-Mannschott wrote on Thu, Sep 22, 2011 at 20:49:35 +0200:
> On Thu, Sep 22, 2011 at 20:40, David Weintraub <qa...@gmail.com> wrote:
> > One of the nice thing about Dropbox is that you can share files
> > between various users. I will sometimes keep a Subversion repository
> > on Dropbox, so I can access it on various systems. Right now, it's
> > just for me to use.
> >
> > Here's the scenario:
> >
> > * I have my Dropbox under $HOME/Dropbox.
> > * I create a Subversion repository on $HOME/Dropbox/svn_repos
> > * I now share my $HOME/Dropbox/svn_repos folder between my colleagues.
> >
> > What happens if we all start svnserve on that particular shared folder
> > in Dropbox? Is there an issue with possible collisions if two or more
> > people attempt to commit their changes at the same time?
>
> Dropbox will rename conflicting revisions. Subversion will become very
> confused. Your repository will be hosed.
>
> > What if we skip the svnserve route and merely use the file://
> > protocol? Is this any safer?
>
> No. This makes no difference. Both will be equally broken.
>
> This is a Bad Idea.
>
+1. Don't do that.
> // Ben
Re: Use of svnserve and Dropbox
Posted by Ben Smith-Mannschott <bs...@gmail.com>.
On Thu, Sep 22, 2011 at 20:40, David Weintraub <qa...@gmail.com> wrote:
> One of the nice thing about Dropbox is that you can share files
> between various users. I will sometimes keep a Subversion repository
> on Dropbox, so I can access it on various systems. Right now, it's
> just for me to use.
>
> Here's the scenario:
>
> * I have my Dropbox under $HOME/Dropbox.
> * I create a Subversion repository on $HOME/Dropbox/svn_repos
> * I now share my $HOME/Dropbox/svn_repos folder between my colleagues.
>
> What happens if we all start svnserve on that particular shared folder
> in Dropbox? Is there an issue with possible collisions if two or more
> people attempt to commit their changes at the same time?
Dropbox will rename conflicting revisions. Subversion will become very
confused. Your repository will be hosed.
> What if we skip the svnserve route and merely use the file://
> protocol? Is this any safer?
No. This makes no difference. Both will be equally broken.
This is a Bad Idea.
// Ben
Re: Use of svnserve and Dropbox
Posted by Les Mikesell <le...@gmail.com>.
On Thu, Sep 22, 2011 at 1:40 PM, David Weintraub <qa...@gmail.com> wrote:
> One of the nice thing about Dropbox is that you can share files
> between various users. I will sometimes keep a Subversion repository
> on Dropbox, so I can access it on various systems. Right now, it's
> just for me to use.
>
> Here's the scenario:
>
> * I have my Dropbox under $HOME/Dropbox.
> * I create a Subversion repository on $HOME/Dropbox/svn_repos
> * I now share my $HOME/Dropbox/svn_repos folder between my colleagues.
>
> What happens if we all start svnserve on that particular shared folder
> in Dropbox? Is there an issue with possible collisions if two or more
> people attempt to commit their changes at the same time?
>
> What if we skip the svnserve route and merely use the file://
> protocol? Is this any safer?
I don't think dropbox has any concept of locking or exclusive access
so things are going to break with concurrent changes.
--
Les Mikesell
lesmikesell@gmail.com