[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Enhancement: displaced .svn

From: Vladimír Marek <vlmarek_at_volny.cz>
Date: 2005-07-20 17:48:38 CEST

> > > This is A VERY BAD IDEA.
> > > If you're working on more than one project, they will all share
> > > metadata if the environment variable is
> > > set.
> >
> > Well, it's true that you have to pay attention, but it's nothing hard.
> > And the metadata directory could contain "it's" working copy path. (
> > This is not bulletproof, but I think that I would work sufficiently )
>
> I chose Subversion because the development team is not satisfied with
> solutions that work 'sufficiently'.
>
> The only way Open Source projects are going to really compete with
> commercial products in commercial environments, is when they don't
> accept 'sufficiently'.
>
> No flame intended

Don't worry, I don't have problem if someone sais me that I'm stupit if
he says why ;)

> I understand what you would like to do. Still it is a
> bad idea. Not only because of what Tommy said, but also because there
> already is a solution to your 'problem':
>
> About a): If you want to create a tree of the dirs and files in your
> repos for shipping to a customer, you can use svn export to export it.
> Also, you could write a nice script for packaging stuff which also
> removes .svn dirs along the way.

Right, I forgot that there is export. Still it could make things easier
in some cases.

> Your suggestion under b) about sharing a working copy over the network
> is really *ugly* and makes me think you did not understand the concept
> of version control or subversion. How are you ever going to say what the
> version of a file is if people have seperate metadata about shared data?
> Remember what metadata means: data about the data. Inconsistency all
> over if you have multiple, *different* data on 'the data' (your working
> copy).

Ok, I'll try to explain a bit more. There's wild shared file system. No
revision control anywhere. I would like to track changes conveniently by
svn but
 *) .svn files would bother other people
 *) the shared fs consumed space would grow twice by adding metadata

Noone else would use that my revision system, and noone else would need
to notice that I'm using it.

Other possibility I'm using right now, is that I'm making copy of that
fs to my local machine, and having that place under revision control.

> About c). What about svnadmin dump? This is not a poor man's incremental
> backup. It is no backup at all. Period.

To do incremental backups using subversion you must add .svn files to
the data. Ok, this is the same as b), just more bizare :)

> Anyway, I hope you understand what I mean, and why your thoughts are
> really not a good idea (although quite original I must say).

Thanks for your comments, Pim

--
	Vladimir

  • application/pgp-signature attachment: stored
Received on Wed Jul 20 17:50:18 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.