On Tue, Mar 20, 2012 at 8:09 AM, Svante Schubert <[email protected]> wrote: > Hi Devin, > > as you did before an ODF Toolkit release at Apache, do you have some > notes you are able to share? >
Devin put up a web page here: http://incubator.apache.org/odftoolkit/odftoolkit-release-guide.html > One comment already. We might want use the subversion tag mechanism > instead of storing each release in a different folder of our svn repository. > Recently I have realized at Jenkins (picture in the upper right of > https://builds.apache.org/job/ODFToolkit/), that the workplace space > jumped up to half a gigabyte around the build #24. > I could not find any changes (see > https://builds.apache.org/job/ODFToolkit/changes), but when I downloaded > the complete repository via "svn co > https://svn.apache.org/repos/asf/incubator/odf/";, I realized a "/tags" > sub folder, with all our release candidates each about 50BM. I fear this > will not scale for the future, especially as Subversion might do the job > via tagging, although I am not a Subversion expert and can not give you > any advice on that. I was new to Subversion, and surprised at this behavior as well. From what I've read, a tag and a branch are exactly the same. They are done via "svn copy. The only difference is convention, whether you store in /tags or /branches. The copy operation is cheap/lazy from the Subversion server's perspective. They do not instantiate storage for the entire copy. However, when you bring down to local file system, via a check-out, it does expand it. So when I download, I download only odf/trunk, in order to avoid /tags. If Jenkins is not doing this, then it is bring down a lot more than necessary. -Rob > Anyone at the list, who can tell us the usual Apache way? > > Best, > Svante >
