----- Original Message -----
From: "B. W. Fitzpatrick" <fitz@red-bean.com>
>
> I'm -1 on this going into Subversion, either pre-1.0 or otherwise.
> While this is a nice feature and could save some people a bit of time
> and energy, I believe that the functionality is completely unrelated
> to version control. It is limited insofar that it can fetch things
> using only http (what about ftp?), and it also introduces YAD (Yet
> Another Dependency) into the Subversion build tree.
I don't think its "completely unrelated to version control". This
feature would help a lot in dealing with third party libraries. Right
now you need to do that with "Vendor branches", i.e. putting
those libraries under version control too. But that means that
the backup of the repository needs a whole lot more space
because the repository itself is bigger.
Even "incremental" backups don't help here 'cause with every
revision the whole repository changes and needs to backed up.
With this feature, you could do a backup only _once_ of the
third party libraries, then put them on the server and never
do a backup of that data again. If the library changes, you
just have to do again _one_ backup and put the new
version of the library on the server too.
If you're dealing with about 10GB of such libs and they
change about two times a year then we're talking about
15 to 20GB additional space the repository needs. And
the most common backup tapes only have a capacity
of 50GB...
I don't know if that's important enough for you but in our
company we're always at the limit of our backup system -
and this feature would help us really a lot.
> This sounds like a great starting feature for a tool that could
> piggyback on svn and query a working copy for 'tarball' properties and
> Do The Right Thing from there.
That could be done, but then it wouldn't be an "official" property
and clients could implement it the way they want. This could end
up in a total mess.
Also, the subversion client doesn't provide a callback (yet).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 12 22:20:17 2003