Re: Releasing an open source subversion client

[Rajith Chathunga]

Hi Subversion,

As you suggested, we have hosted the source code in Google Code. It will be
great if you can take a look at it and give your suggestions/feedback.
Here is the checkout link : http://visiosvn.googlecode.com/svn/trunk/
Thank you.
-- 
Cheers,
Chathunga

Re: Releasing an open source subversion client

[Lorenz]

VisioSVN Project wrote:
>We are from university of Moratuwa, Sri Lanka and our team is developing an
>open source Subversion client as our internship project. We have discussed
>about this VisioSVN project before and as you suggested we have hosted the
>source code in Google Code. It will be great if you can take a look at it
>and give your suggestions/feedbacks. This is the URL where you can checkout
>the source code :
>*http*://visiosvn.googlecode.com/svn/trunk/

I think you should reconsider the name choice.

My first thought was: "oh nice, svn-integration with MS-Visio. Does it
have a graphical diff-tool for visio charts?"

but, I rejoiced too soon ...
-- 

Lorenz

SVN

[Sukumar Gorai]

Why we need SVN setup? And if is important then how to install? Please
explain and how to use SVN?

-- 
Regards,
Sukumar Gorai
Jr. Software Developer
Bluehorse Software
email-sukumar.go...@bluehorse.in 
Mob-+91-8296015120
   +91-9647555891

Re: SVN

[Geoff Hoffman]

Read this http://svnbook.red-bean.com/


On Thu, Sep 22, 2011 at 5:37 AM, Sukumar Gorai
wrote:

> Why we need SVN setup? And if is important then how to install? Please
> explain and how to use SVN?
>
> --
> Regards,
> Sukumar Gorai
> Jr. Software Developer
> Bluehorse Software
> email-sukumar.go...@bluehorse.in 
> Mob-+91-8296015120
>+91-9647555891
>

Use of svnserve and Dropbox

[David Weintraub]

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
qazw...@gmail.com

Re: SVN

[Chris Albertson]

As other have pointed out, this a book length subject. but there is
even more to it.  First you have to answer "what will version control
fit into my software development process"  What you will find is you
wil also need some system to track bugs and progress on fixing them
and a way to relate software versions to which bug fixes and new
features.The subject is large enough that one book can't over it.

On Thu, Sep 22, 2011 at 5:37 AM, Sukumar Gorai
 wrote:
> Why we need SVN setup? And if is important then how to install? Please
> explain and how to use SVN?
> --
> Regards,
> Sukumar Gorai
> Jr. Software Developer
> Bluehorse Software
> email-sukumar.go...@bluehorse.in
> Mob-+91-8296015120
>        +91-9647555891
>



-- 

Chris Albertson
Redondo Beach, California

Re: Use of svnserve and Dropbox

[Chris Albertson]

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  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
> qazw...@gmail.com
>



-- 

Chris Albertson
Redondo Beach, California

Re: Use of svnserve and Dropbox

[Les Mikesell]

On Thu, Sep 22, 2011 at 1:40 PM, David Weintraub  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
 lesmikes...@gmail.com

Re: Use of svnserve and Dropbox

[Ben Smith-Mannschott]

On Thu, Sep 22, 2011 at 20:40, David Weintraub  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: Discovery file type by logs.

[Marcello Henrique]

Hello everybody,

I will help you for you help me. I created one script with my problem,
for see whether somebody advice.

By documentation [0], See in line 20 into attachments, I should not
have one struct of type [1] identical of the line 18 [2] with just
difference of extended fields (node_kind, text_modified,
props_modifed)?

Is necessary install libsvn-ruby1.8 and ruby1.8, for use mode:

$ ruby esc_debug.rb -f9 -l1 https://svn.cercomp.ufg.br/pub/weby

[0] http://svn.collab.net/svn-doxygen/structsvn__log__entry__t.html
[1] http://svn.collab.net/svn-doxygen/structsvn__log__changed__path2__t.html
[2] http://svn.collab.net/svn-doxygen/structsvn__log__changed__path__t.html

Thanks again.

On Tue, Sep 20, 2011 at 13:09, Marcello Henrique  wrote:
> Hello,
>
> I will change the question: Using libsvn, how I will discover the file
> type (file, directory) into logs iterations?
>
> Thanks.
>
> On Sat, Sep 17, 2011 at 01:03, Marcello Henrique  wrote:
>> Hello,
>>
>> I have use "Svn::Ext::Client.svn_client_log5" into ruby language, I
>> get structure type "_p_svn_log_changed_path_t", I need the node.kind
>> proposed by "changed_paths2" for discovery the file type. What's the
>> better form have do it?
>>
>> I tried "changed_paths2" but returned "_p_apr_hash_t" as file type,
>> indeed not should be "_p_svn_log_changed_path_t" as is into
>> documentation?
>>
>> I'm sorry any bad explanation.
>> Thanks.
>> --
>> Marcello Henrique
>> Blog - http://faraohh.wordpress.com
>> Equipe Web - Cercomp - UFG (www.cercomp.ufg.br)
>> Associação Software Livre de Goiás (www.aslgo.org.br)
>>
>
>
>
> --
> Marcello Henrique
> Blog - http://faraohh.wordpress.com
> Equipe Web - Cercomp - UFG (www.cercomp.ufg.br)
> Associação Software Livre de Goiás (www.aslgo.org.br)
>



-- 
Marcello Henrique
Blog - http://faraohh.wordpress.com
Equipe Web - Cercomp - UFG (www.cercomp.ufg.br)
Associação Software Livre de Goiás (www.aslgo.org.br)


esc_debug.rb
Description: application/ruby

Re: Use of svnserve and Dropbox

[Daniel Shahaf]

Ben Smith-Mannschott wrote on Thu, Sep 22, 2011 at 20:49:35 +0200:
> On Thu, Sep 22, 2011 at 20:40, David Weintraub  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

[Chris Albertson]

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

[David Weintraub]

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
qazw...@gmail.com

Re: Use of svnserve and Dropbox

[Daniel Shahaf]

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

[Andreas Krey]

On Fri, 23 Sep 2011 01:18:28 +, 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