You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andy Levy <an...@gmail.com> on 2009/05/13 12:31:08 UTC
Re: How to avoid cluttering the svn repository with several
versions of compiled files
On Wed, May 13, 2009 at 07:26, Dymetman, Marc
<Ma...@xrce.xerox.com> wrote:
> Hi, I am a newbie to SVN, and have the following question:
>
>
>
> Suppose that I am collaborating with several people on producing a book
> using LaTeX.
>
> I would like to use SVN not only for versioning the sources, but also I
> would like to have in the repository an up-to-date version of the .pdf (or
> .dvi, or .ps) compiled from these sources. The reason for that is that,
> although the pdf is recoverable from the sources, it is convenient for
> everybody to see the latest version without having to recompile the sources.
>
> I could compile the pdf in my working copy, and add it to the svn
> repository, but then I would be cluttering the repository with many versions
> of the pdf (for which SVN is probably not doing a good job at incremental
> diffs).
>
>
>
> Is there a way to tell SVN that the latest pdf file should *replace* the
> previous one, that is, to force deletion of the previous revisions of that
> file?
>
> Of course I could save the pdf file somewhere else, not under version
> control, but perhaps there is a way to do that inside svn?
>
> (I guess my question would also make sense for binaries compiled from
> programs, not only for Latex docs).
If you can produce your compiled item from resources in the repository
(sources, stylesheets, makefiles, etc.), then there's no real need to
store the compiled items themselves - you can reproduce them anytime
you want in the future. Most people *don't* keep compiled binaries in
their repositories.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2236698
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Re: How to avoid cluttering the svn repository with several
versions of compiled files
Posted by we...@tigris.org.
Thanks to Andreas and Andy for the detailed responses.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2239089
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: How to avoid cluttering the svn repository with several
versions of compiled files
Posted by Andreas Schweigstill <an...@schweigstill.de>.
Hello!
Les Mikesell schrieb:
> 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?
There is not plan to remove such official software releases from the
repository. In this specific project the source part of the repository
is about 4GB. Every official release generated about 20MB of binary
files. There are about 10 official releases per year. So where is the
problem?
Storing such binary files on a file server also uses some space, about
the same amount as in a SVN repository. I have to admit that onn the
customer's site the siles are also stored on a file server for people
who don't have SVN accounts.
I know that there are many projects where the generated binaries are
much bigger than the source files, so it could really be a problem
to stuff them into SVN.
> 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.
In this project the generated files have to be kept forever in order to
fulfill requirements of the certification authorities. And also I think
that it would really, really bad practice to delete any file which was
an important part of released products, especially for product which
have a life cycle of >=10 years.
Regards
Andreas Schweigstill
--
BITTE BEACHTEN SIE UNSERE NEUE TELEFONNUMMER!
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 53035-435, Fax: (+49) 431 53035-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2268532
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: How to avoid cluttering the svn repository with several
versions of compiled files
Posted by Les Mikesell <le...@gmail.com>.
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@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2258805
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: How to avoid cluttering the svn repository with several
versions of compiled files
Posted by Andreas Schweigstill <an...@schweigstill.de>.
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. 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.
Regards
Andreas Schweigstill
--
BITTE BEACHTEN SIE UNSERE NEUE TELEFONNUMMER!
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 53035-435, Fax: (+49) 431 53035-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2258217
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: How to avoid cluttering the svn repository with several
versions of compiled files
Posted by Andy Levy <an...@gmail.com>.
On Wed, May 13, 2009 at 11:31, Andreas Schweigstill
<an...@schweigstill.de> wrote:
> Hello!
>
> Andy Levy schrieb:
>> If you can produce your compiled item from resources in the repository
>> (sources, stylesheets, makefiles, etc.), then there's no real need to
>> store the compiled items themselves - you can reproduce them anytime
>> you want in the future. Most people *don't* keep compiled binaries in
>> their repositories.
>
> Hmm, a reproduction of old generated files is only possible if the build
> environment hasn't changed and if there are no other influences to the
> build process, e.g. timestamps or random generator data.
>
> When I do an offical software release I distinguish between "trunk",
> "tags", "branches" and "releases", so the repository has the following
> structure:
> Since the copied content of "trunk" is located in the "sources"
> subdirectory of "releases/version1" and not in the root it is possible
> to create multiple other directories, e.g. to store the generated
> binary files. Especially if the build process contains build steps which
> have to be asynchronously or seperated from the main build the
> "binaries" directory will also be used as a transfer directory for those
> special build steps.
>
> And also some kind of release documents which are created outside the
> software build process can be stored in their own directories below
> "releases/version1", e.g. release notes which have been created by an
> external certification authority.
>
> So there are lots of reasons to store generated documents in a
> Subversion repository. But it would be really bad practice to mix source
> files with generated files, e.g. put object files in the same
> directories as source files.
For this sort of setup, I wouldn't even put the compiled items into
the repository. I would create a separate "release archive" which is
built from a tag when a release is prepared. 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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2239396
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: How to avoid cluttering the svn repository with several
versions of compiled files
Posted by Andreas Schweigstill <an...@schweigstill.de>.
Hello!
Andy Levy schrieb:
> If you can produce your compiled item from resources in the repository
> (sources, stylesheets, makefiles, etc.), then there's no real need to
> store the compiled items themselves - you can reproduce them anytime
> you want in the future. Most people *don't* keep compiled binaries in
> their repositories.
Hmm, a reproduction of old generated files is only possible if the build
environment hasn't changed and if there are no other influences to the
build process, e.g. timestamps or random generator data.
When I do an offical software release I distinguish between "trunk",
"tags", "branches" and "releases", so the repository has the following
structure:
my_project
-- trunk
| -- dir1
| -- dir2
|
-- tags
|
-- branches
| -- branch1
| | -- dir1
| | -- dir2
| -- branch2
|
-- releases
-- version1
| -- sources
| -- dir1
| -- dir2
| -- binaries
| file1.bin
| filexy.elf
| build_sources_and_copy_to_binaries_dir.sh
| build_sources_and_copy_to_binaries_dir.log
-- version2
-- sources
-- dir1
-- dir2
-- binaries
file1.bin
filexy.elf
build_sources_and_copy_to_binaries_dir.sh
build_sources_and_copy_to_binaries_dir.log
The "tags" directory structure will only be used to store certain
milestones of a project which are not identical to official product
releases.
Since the copied content of "trunk" is located in the "sources"
subdirectory of "releases/version1" and not in the root it is possible
to create multiple other directories, e.g. to store the generated
binary files. Especially if the build process contains build steps which
have to be asynchronously or seperated from the main build the
"binaries" directory will also be used as a transfer directory for those
special build steps.
And also some kind of release documents which are created outside the
software build process can be stored in their own directories below
"releases/version1", e.g. release notes which have been created by an
external certification authority.
So there are lots of reasons to store generated documents in a
Subversion repository. But it would be really bad practice to mix source
files with generated files, e.g. put object files in the same
directories as source files.
Regards
Andreas Schweigstill
--
BITTE BEACHTEN SIE UNSERE NEUE TELEFONNUMMER!
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 53035-435, Fax: (+49) 431 53035-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2239351
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].