Hi All, For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Hi All,
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
I use the Vault to distribute .zip archives of newer versions of my libraries. I wouldn't want to have to tell people they need a subversion client to get out-of-band bug fixes and features. I say leave it alone. My $0.02, -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
David Abrahams wrote:
Hi All,
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
I use the Vault to distribute .zip archives of newer versions of my libraries. I wouldn't want to have to tell people they need a subversion client to get out-of-band bug fixes and features. I say leave it alone. My $0.02,
Add my 2 cents too. There is lot's of code there which the author doesn't have time to massage to boost requirements but is still very valuable. In particular there are modules for serialization of a few types which work fine even though there are no tests, documentation etc. Look at the number of downloads. Robert Ramey
on Thu Jan 22 2009, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Eric Niebler wrote:
David Abrahams wrote:
Hi All,
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
I use the Vault to distribute .zip archives of newer versions of my libraries. I wouldn't want to have to tell people they need a subversion client to get out-of-band bug fixes and features. I say leave it alone.
I think you can do most of that with Trac. See the zip archive link at the bottom of https://svn.boost.org/trac/boost/changeset?new=48077%40trunk%2Flibs%2Fxpressive&old=46368%40trunk%2Flibs%2Fxpressive
My $0.02,
Add my 2 cents too.
There is lot's of code there which the author doesn't have time to massage to boost requirements but is still very valuable.
That can still go in the sandbox. The sandbox is for in-development stuff.
In particular there are modules for serialization of a few types which work fine even though there are no tests, documentation etc. Look at the number of downloads.
I don't see how that relates to vault vs. SVN. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Eric Niebler wrote:
I use the Vault to distribute .zip archives of newer versions of my libraries. I wouldn't want to have to tell people they need a subversion client to get out-of-band bug fixes and features. I say leave it alone.
I think you can do most of that with Trac. See the zip archive link at the bottom of https://svn.boost.org/trac/boost/changeset?new=48077%40trunk%2Flibs%2Fxpressive&old=46368%40trunk%2Flibs%2Fxpressive
I just looked at that archive. It contains only the files that were affected by that particular changeset. That's nothing at all like a packaged release of Boost.Xpressive, complete with docs in html and pdf format, and thoroughly tested with the latest boost release. Where would I put that, if not for the Vault? -- Eric Niebler BoostPro Computing http://www.boostpro.com
on Thu Jan 22 2009, Eric Niebler <eric-AT-boost-consulting.com> wrote:
David Abrahams wrote:
Eric Niebler wrote:
I use the Vault to distribute .zip archives of newer versions of my libraries. I wouldn't want to have to tell people they need a subversion client to get out-of-band bug fixes and features. I say leave it alone.
I think you can do most of that with Trac. See the zip archive link at the bottom of
I just looked at that archive. It contains only the files that were affected by that particular changeset. That's nothing at all like a packaged release of Boost.Xpressive, complete with docs in html and pdf format, and thoroughly tested with the latest boost release. Where would I put that, if not for the Vault?
I guess you could attach it to a Trac wiki page. -- Dave Abrahams BoostPro Computing http://boostpro.com
on Thu Jan 22 2009, David Abrahams <dave-AT-boostpro.com> wrote:
on Thu Jan 22 2009, Eric Niebler <eric-AT-boost-consulting.com> wrote:
I just looked at that archive. It contains only the files that were affected by that particular changeset. That's nothing at all like a packaged release of Boost.Xpressive, complete with docs in html and pdf format, and thoroughly tested with the latest boost release. Where would I put that, if not for the Vault?
I guess you could attach it to a Trac wiki page.
Or check it into svn and point people at that: http://svn.boost.org/svn/boost/sandbox/ -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Robert Ramey wrote:
Eric Niebler wrote:
Hi All,
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted? I use the Vault to distribute .zip archives of newer versions of my
David Abrahams wrote: libraries. I wouldn't want to have to tell people they need a subversion client to get out-of-band bug fixes and features. I say leave it alone. My $0.02,
Add my 2 cents too.
There is lot's of code there which the author doesn't have time to massage to boost requirements but is still very valuable. In particular there are modules for serialization of a few types which work fine even though there are no tests, documentation etc. Look at the number of downloads.
What about the sandbox says that the code has to fit Boost requirements ? Can't it just be a common place where potential Boost software is uploaded ? I do not see why not. Having two totally different places where potential Boost software is presented for others to look at/try etc. seems unnecessary to me on principle, even as a software developer who has not written anything for Boost.
Eric Niebler wrote:
David Abrahams wrote:
Hi All,
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
I use the Vault to distribute .zip archives of newer versions of my libraries. I wouldn't want to have to tell people they need a subversion client to get out-of-band bug fixes and features. I say leave it alone.
My $0.02,
Why can't you just stick the zip file into the sandbox. Is there not a subversion web interface for the sandbox ? Is not subversion 100% free ? I have tried to question the entire business of Boost having two different places where potential software is uploaded in the past. I think it is just confusing, and a single place where potential Boost software is uploaded is much better.
----- Original Message ----- From: "David Abrahams" <dave@boostpro.com> To: "boost" <boost@lists.boost.org> Sent: Thursday, January 22, 2009 8:21 PM Subject: [boost] Vault: still needed?
Hi All,
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
Hi, I think that most of the libraries that you find in the sandbox do not include the html documentation, while the compressed files in the Vault include them. I see authors that store several versions of its libraries. If Boost.Vault have problems with the space we should preserv the last version of each library and remove the old ones. My 0.02, Vicente
on Thu Jan 22 2009, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:
Hi, I think that most of the libraries that you find in the sandbox do not include the html documentation, while the compressed files in the Vault include them.
Maybe, but there's no reason we couldn't check the html into the sandbox.
I see authors that store several versions of its libraries.
svn cp (tagging) works great.
If Boost.Vault have problems with the space we should preserv the last version of each library and remove the old ones.
It's not so much a space problem as an organizational concern over redundant facilities and people not knowing where to look for (or put) things. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
----- Original Message ----- From: "David Abrahams" <dave@boostpro.com> To: <boost@lists.boost.org> Sent: Thursday, January 22, 2009 9:52 PM Subject: Re: [boost] Vault: still needed?
on Thu Jan 22 2009, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:
Hi, I think that most of the libraries that you find in the sandbox do not include the html documentation, while the compressed files in the Vault include them.
Maybe, but there's no reason we couldn't check the html into the sandbox.
The isuue is not about check but about removing the no more useful files. It is not easy to see which files can be removed. I realy think that both are complementaty, not every people has acces to SVN.
I see authors that store several versions of its libraries.
svn cp (tagging) works great.
If Boost.Vault have problems with the space we should preserv the last version of each library and remove the old ones.
It's not so much a space problem as an organizational concern over redundant facilities and people not knowing where to look for (or put) things.
Yes you are right, it is difficult to know. For locking for there is the Library Under Construction wiki page. If the authors use to use it the people looking for will not have major problems. The case of people asking to where they can put its new library occurs not very offten, and they use to look for other libraries, so they will finish by knowing the Library Under Construction wiki page. Regards, Vicente
on Thu Jan 22 2009, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:
Hi, I think that most of the libraries that you find in the sandbox do not include the html documentation, while the compressed files in the Vault include them. I see authors that store several versions of its libraries. If Boost.Vault have problems with the space we should preserv the last version of each library and remove the old ones.
Well, frankly I don't love the idea that the vault's php code is running on our server at all; I don't trust it all that much, and I don't think we're spending any resources on backing that data up. I think Subversion is a much more reliable way to do this, and as a bonus the revisions will all be trackable. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Jan 22, 2009 at 14:21, David Abrahams <dave@boostpro.com> wrote:
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
What are the requirements for access to the sandbox? I used the vault to upload an alternate version of the uuid library a while back, when I don't have and am not currently planning on getting a sandbox account. Requiring that the code be in the sandbox before a review seems like a reasonable requirement, though. Being able to propose modifications as SVN diffs would be convenient. ~ Scott McMurray
on Thu Jan 22 2009, Scott McMurray <me22.ca+boost-AT-gmail.com> wrote:
On Thu, Jan 22, 2009 at 14:21, David Abrahams <dave@boostpro.com> wrote:
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
What are the requirements for access to the sandbox?
Anyone can read it. Ask for an invitation and you can write it, too. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Jan 22, 2009 at 11:21 AM, David Abrahams <dave@boostpro.com> wrote:
Hi All,
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
If the only purpose of the vault is as a storage for things before they get fully boostified, then there's no need for it. But my understanding is that it contains things that may never become official part of Boost. In that case, the vault provides means for distribution of Boost-related files, for which SVN is inadequate for the same reason it's inadequate to be the only way to distribute Boost itself. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Thu, Jan 22, 2009 at 11:21 AM, David Abrahams <dave@boostpro.com> wrote:
Hi All,
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
If the only purpose of the vault is as a storage for things before they get fully boostified, then there's no need for it.
But my understanding is that it contains things that may never become official part of Boost. In that case, the vault provides means for distribution of Boost-related files, for which SVN is inadequate for the same reason it's inadequate to be the only way to distribute Boost itself.
I'll bite. What is "the same reason [SVN is] inadequate to be the only way to distribute Boost itself" and why should this have anything to do with the sandbox as a way to distribute Boost-related software ?
On Thu, Jan 22, 2009 at 3:24 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
Emil Dotchevski wrote:
But my understanding is that it contains things that may never become official part of Boost. In that case, the vault provides means for distribution of Boost-related files, for which SVN is inadequate for the same reason it's inadequate to be the only way to distribute Boost itself.
I'll bite. What is "the same reason [SVN is] inadequate to be the only way to distribute Boost itself" and why should this have anything to do with the sandbox as a way to distribute Boost-related software ?
I mean, we could distribute Boost by placing releases in SVN (let's say in a "releases" folder), and have users download them through the web SVN access, but instead we distribute Boost through SourceForge. This is simpler than having to dig through the SVN repository to figure out what to download, etc. The Boost Vault is similarly simpler than a giant SVN tree (I suppose the word "inadequate" was a bit excessive.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
on Thu Jan 22 2009, Emil Dotchevski <emildotchevski-AT-gmail.com> wrote:
On Thu, Jan 22, 2009 at 3:24 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
Emil Dotchevski wrote:
But my understanding is that it contains things that may never become official part of Boost. In that case, the vault provides means for distribution of Boost-related files, for which SVN is inadequate for the same reason it's inadequate to be the only way to distribute Boost itself.
I'll bite. What is "the same reason [SVN is] inadequate to be the only way to distribute Boost itself" and why should this have anything to do with the sandbox as a way to distribute Boost-related software ?
I mean, we could distribute Boost by placing releases in SVN (let's say in a "releases" folder), and have users download them through the web SVN access, but instead we distribute Boost through SourceForge.
The main reason for that is that SF has mirrors which can handle the traffic. Doesn't really apply to sandbox stuff.
This is simpler than having to dig through the SVN repository to figure out what to download, etc.
Hmm, http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&release_id=637761 vs http://svn.boost.org/svn/boost/vault/xxx I like the latter better.
The Boost Vault is similarly simpler than a giant SVN tree (I suppose the word "inadequate" was a bit excessive.)
In what way is it simpler? It appears to be a giant directory tree, too. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Jan 22, 2009 at 10:08 PM, David Abrahams >> The Boost Vault is similarly simpler than a giant SVN tree (I suppose
the word "inadequate" was a bit excessive.)
In what way is it simpler? It appears to be a giant directory tree, too.
I appears that I've misinterpreted what the vault really is. You're right, it's also a giant directory tree, the main difference seems to be that it contains "packages" as opposed to raw files. Or am I off on this too? :) I still don't understand why it makes sense for the vault packages to be in SVN, but the official Boost distribution has to be in sourceforge. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
on Fri Jan 23 2009, Emil Dotchevski <emildotchevski-AT-gmail.com> wrote:
On Thu, Jan 22, 2009 at 10:08 PM, David Abrahams >> The Boost Vault is similarly simpler than a giant SVN tree (I suppose
the word "inadequate" was a bit excessive.)
In what way is it simpler? It appears to be a giant directory tree, too.
I appears that I've misinterpreted what the vault really is. You're right, it's also a giant directory tree, the main difference seems to be that it contains "packages" as opposed to raw files. Or am I off on this too? :)
I still don't understand why it makes sense for the vault packages to be in SVN, but the official Boost distribution has to be in sourceforge.
Mirrors and traffic, my man. We could switch the SF thing, but when we make a new release and people all over the world hit our SVN server, taking it down and stopping development, you'll wish we were using the SF release system again. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
This is simpler than having to dig through the SVN repository to figure out what to download, etc.
Hmm,
http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=80 41&release_id=637761
vs
http://svn.boost.org/svn/boost/vault/xxx
I like the latter better.
Should the SVN repository be used like the vault, so that .zip files are put to a certain place? Or should it be used like a source code management system? I guess the later is to be preferred. But let's analyze the version with the .zip files a bit. - A user wants to upload a .zip file to the SVN vault. So he checks out the vault directory ("svn co https://svn.boost.org/svn/boost/vault boost_vault", which will probably take 10-30 minutes because of all the data in it), adds his file to the repository (cd boost_vault; cp ~/MyLib.zip .; svn add MyLib.zip) and commits it (svn ci --message "added first version of MyLib, a library intended for doing My stuff"). - A user wants to update his library. He can either add another .zip file with a new name, or just update the existing .zip file - Another user wants to browse the vault. He opens it in a webbrowser directed at http://svn.boost.org/svn/boost/vault and browses it. When he wants to try a library, he just clicks on the .zip file and downloads it. Very satisfying experience. - Another user wants to use svn to do the same thing. So he checks out the vault directory ("svn co http://svn.boost.org/svn/boost/vault boost_vault", which will probably take 10-30 minutes because of all the data in it), and the uses the directory browser of his os to browse the vault. When he wants to try a library he has to decompress the .zip file to some place. A unusual experience, but why not. - Another user wants to see what changed between different versions of a library in the vault. He decompresses the .zip files into different places, and compares them with diff tools. He will find out what's different, but will have no way of knowing why it was changed, because there are no commit messages.
The Boost Vault is similarly simpler than a giant SVN tree (I suppose the word "inadequate" was a bit excessive.)
In what way is it simpler? It appears to be a giant directory tree, too.
In the it is clear that this tree is supposed to hold compressed archives. It's also clear how the tree is meant to be browsed. It's much simpler to remove something "forever", which can be quite difficult in a version control system. Regards, Thomas
Emil Dotchevski wrote:
On Thu, Jan 22, 2009 at 3:24 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
Emil Dotchevski wrote:
But my understanding is that it contains things that may never become official part of Boost. In that case, the vault provides means for distribution of Boost-related files, for which SVN is inadequate for the same reason it's inadequate to be the only way to distribute Boost itself. I'll bite. What is "the same reason [SVN is] inadequate to be the only way to distribute Boost itself" and why should this have anything to do with the sandbox as a way to distribute Boost-related software ?
I mean, we could distribute Boost by placing releases in SVN (let's say in a "releases" folder), and have users download them through the web SVN access, but instead we distribute Boost through SourceForge. This is simpler than having to dig through the SVN repository to figure out what to download, etc.
Releasing Boost is a relatively infrequent process compared to new software or updates in the Boost sandbox/Boost vault, which occur regularly. That's why having a separate place on sourceforge for complete Boost releases while the latest Boost is under SVN does not impact anyone negatively.
The Boost Vault is similarly simpler than a giant SVN tree (I suppose the word "inadequate" was a bit excessive.)
One can place anything under SVN, including entire implementations in compressed file format, in any branch of SVN. Why not simply have a "Vault" branch of Boost's SVN and then have everyone who is used to using the Boost Vault place there software there. The end user could then use the "Vault" branch of Boost's SVN to get at it, and this would not impact other users of Boost's SVN from getting the latest Boost from the "trunk" in any way whatsoever. At least in this way there would be a single central repository where all potential Boost software resides, including new releases etc. People really need to get with the idea that SVN can be used for any type of software being released rather than thinking of it as only software undergoing incremental changes.
Edward Diener wrote:
Emil Dotchevski wrote:
The Boost Vault is similarly simpler than a giant SVN tree (I suppose the word "inadequate" was a bit excessive.)
One can place anything under SVN, including entire implementations in compressed file format, in any branch of SVN. Why not simply have a "Vault" branch of Boost's SVN and then have everyone who is used to using the Boost Vault place there software there. The end user could then use the "Vault" branch of Boost's SVN to get at it, and this would not impact other users of Boost's SVN from getting the latest Boost from the "trunk" in any way whatsoever.
I agree with this proposal. I think a "Vault" directory in SVN (maybe, inside the sandbox repository) is a good idea. However, I'd like the major advantage of the Vault to be preserved - this directory should be accessible without having SVN installed. I would suggest to switch the "Vault" reference in the web site to the appropriate page of web-SVN. At least until people get accustomed with the idea that it is now in the sandbox. As a side question, what will happen with the current Vault contents? Will it move under SVN or should the file owners move it themselves?
on Fri Jan 23 2009, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
Edward Diener wrote:
Emil Dotchevski wrote:
The Boost Vault is similarly simpler than a giant SVN tree (I suppose the word "inadequate" was a bit excessive.)
One can place anything under SVN, including entire implementations in compressed file format, in any branch of SVN. Why not simply have a "Vault" branch of Boost's SVN and then have everyone who is used to using the Boost Vault place there software there. The end user could then use the "Vault" branch of Boost's SVN to get at it, and this would not impact other users of Boost's SVN from getting the latest Boost from the "trunk" in any way whatsoever.
I agree with this proposal. I think a "Vault" directory in SVN (maybe, inside the sandbox repository) is a good idea. However, I'd like the major advantage of the Vault to be preserved - this directory should be accessible without having SVN installed. I would suggest to switch the "Vault" reference in the web site to the appropriate page of web-SVN. At least until people get accustomed with the idea that it is now in the sandbox.
As a side question, what will happen with the current Vault contents? Will it move under SVN or should the file owners move it themselves?
Well, we'd need to reach consensus that this *should* be done, first... However, I think if the process is automatable we'd be happy to handle the move. Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Thu Jan 22 2009, Emil Dotchevski <emildotchevski-AT-gmail.com> wrote:
On Thu, Jan 22, 2009 at 11:21 AM, David Abrahams <dave@boostpro.com> wrote:
Hi All,
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted?
If the only purpose of the vault is as a storage for things before they get fully boostified, then there's no need for it.
But my understanding is that it contains things that may never become official part of Boost.
As does the sandbox.
In that case, the vault provides means for distribution of Boost-related files, for which SVN is inadequate for the same reason it's inadequate to be the only way to distribute Boost itself.
Hmm, I'm still not getting it. You can even check the files into SVN and hand out nice URLs: http://svn.boost.org/svn/boost/sandbox/ -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams <dave <at> boostpro.com> writes:
For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed.
Hooray! Finally! So often I was in despair when I read the boost archives referring to vault packages which no longer existed. Using SVN now gives us all we need to track back any action that has taken place: I checkout the sandbox for a given date et voila: I find the submitted tar.gz or zip file of the original proposal and can compare the discussion against this package. The value of this cannot be underestimated. It makes a review process trackable for years. It gives us history. There is an other advantage, too: Since SVN has binary diff storage, the disk usage is lower than in a simple file repo. I really recommend to hold *any* file under SVN. Also I like the many extra possibilities like e.g. WebDAV access (davfs2, etc. ) I support your proposal and I would like to see the vault under version control ASAP. best regards, Markus
On Fri, Jan 23, 2009 at 11:38 AM, Markus Werle <numerical.simulation@web.de> wrote:
I checkout the sandbox for a given date et voila: I find the submitted tar.gz or zip file of the original proposal and can compare the discussion against this package.
There is an other advantage, too: Since SVN has binary diff storage, the disk usage is lower than in a simple file repo. I really recommend to hold *any* file under SVN. Also I like the many extra possibilities like e.g. WebDAV access (davfs2, etc. )
Both for the diffing purpose and for repo size (a small change in a zip, can change the archive a lot, invalidating the smartness of svn binary diff), I think zips should be avoided (forbidden?) in the repository. /$
on Fri Jan 23 2009, Henrik Sundberg <storangen-AT-gmail.com> wrote:
On Fri, Jan 23, 2009 at 11:38 AM, Markus Werle <numerical.simulation@web.de> wrote:
I checkout the sandbox for a given date et voila: I find the submitted tar.gz or zip file of the original proposal and can compare the discussion against this package.
There is an other advantage, too: Since SVN has binary diff storage, the disk usage is lower than in a simple file repo. I really recommend to hold *any* file under SVN. Also I like the many extra possibilities like e.g. WebDAV access (davfs2, etc. )
Both for the diffing purpose and for repo size (a small change in a zip, can change the archive a lot, invalidating the smartness of svn binary diff), I think zips should be avoided (forbidden?) in the repository.
Maybe, but that sort of invalidates one of the useful things about the vault. Maybe it'd be better to use trac wiki attachments for .zip files. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (11)
-
Andrey Semashev -
David Abrahams -
Edward Diener -
Emil Dotchevski -
Eric Niebler -
Henrik Sundberg -
Markus Werle -
Robert Ramey -
Scott McMurray -
Thomas Klimpel -
vicente.botet