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

RE: Re: RFE: new kind of unversioned files

From: Daniel Becroft <Daniel.Becroft_at_supercorp.com.au>
Date: Wed, 7 May 2008 17:25:54 +1000

 

> -----Original Message-----
> From: fkater_at_googlemail.com [mailto:fkater_at_googlemail.com]
> Sent: Wednesday, 7 May 2008 4:14 PM
> To: dev_at_subversion.tigris.org
> Subject: Re: RFE: new kind of unversioned files
>
> Max Bowsher:
>
> > I find it hard to accept that, having decided to use a
> version control
> > system at all, disk space can be at such a premium that it is worth
> > sacrificing the ability to roll back to previous versions.
>
> Yes, disk space is not the main point -- however, it hurts a
> bit if repeated releases of 3rd party's software (in our
> case) leads to repeated updates of this branch by 50 MB each
> time, with 95% stuff we do not need (but no chance to know it
> in advance). So, a simple 'overwrite feature' would be nice to have.
>
>
> > I don't buy the argument about "disabling the feature of
> using older
> > versions" - simply not updating allows for that.
>
> I agree, however, one might see it from this view:
>
> (a) Isn't it the average case that in large trees people do
> not need version control for 100% of the files?
>
> (b) Wouldn't it be useful e.g. for programmers to include
> binary libraries (DLLs, whatever) into the repository
> (without version control!) to pass the latest version only to
> the others without forcing them to build the libraries?

True, but what happens if the users need to use a previous revision?
This becomes impossible, as you have forced all versions of a particular
.DLL, etc. to be the latest, without retaining history of the previous
versions.

> (c) Why not use the ability of file centralization and
> distribution which comes along with subversion separately
> from version management.
>
>
> I am not a subversion programmer but believe that an
> 'overwrite' feature could be realized by some kind of property.

I, too, am not a subversion programmer, but I also belive that such a
property would cause more problems than it would solve. Have you thought
about setting up an external repository containing only the third party
software releases? This way the 'overwritten' files appear to be, well,
overwritten, but the version history remains.

An alternative solution, maybe, would be to allow for a purely
file-based 'externals' type property, that simply performs a file-system
copy from the source-location to the destination, rather than a SVN
checkout operation.

E.g.
        \trunk
                \subdir1
                \subdir2
                \third-party -> svn:fs-externals =
\\some_file_server\shared_path\folder_name
        
        \branches
        \tags

I'm not advocating this solution over any other, just throwing it out
there as an idea.

Cheers,
Daniel B.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-07 09:23:37 CEST

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

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