Andreas Schweigstill wrote:
> Hello!
>
> Andy Levy schrieb:
>> Aside from space
>> efficiencies (which may not even be realized, due these being binary
>> files), there's not much to be gained by putting releases into
>> Subversion instead of a decently-structured archive directory on a
>> server.
>
> But this requires access to a file server which is not always given.
> For some customer projects I only have a VPN connection to the SVN
> server.
>
> And I think I make really a lot of sense to keep source and binaries
> for such purposes in a common location.
So what's your plan for removing obsolete space-wasting binaries after
the repository grows to a size that is inconvenient to maintain and back up?
> File server locations don't
> allow/force the user to put a message directly onto the stored files.
> It would be possible to create files like README.txt or RELEASENOTES.txt
> but they don't "stick" to the generated binaries.
File servers would let you put anything you want on them. You'd
probably want automated build tools for the project to ensure that the
binaries at a location actually matched the expected source
revision/tag. A compromise approach might be to maintain separate
subversion repositories for the binaries with a tag naming convention
for the contents. That would let you use the same set of tools for
remote access and with http(s) you could make the URL's look similar.
Then you could periodically extract the few currently-useful versions
and delete and rebuild the repository without bothering the one holding
the source where you probably want the full history.
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2258805
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-14 17:35:59 CEST