On Thu, May 14, 2009 at 5:20 AM, Bolstridge, Andrew
<andy.bolstridge_at_intergraph.com> wrote:
> That makes sense, but it's not that common a practice, and often
> rebuilding old revisions can be a real nightmare when all you want is an
> old release to test a bug or re-send to a customer.
That's what the release repository is for: Storing the builds, so you
don't have to rebuild them.
We use both Hudson and Nexus. Hudson is our continuous build engine,
and we store the daily builds on Hudson, and depending upon the
project, we store either the last 20 builds or at least three months
worth of builds(which ever is greater). Developers and QA simply
retrieve the builds they want from Hudson.
For releases, we use Nexus as our release repository. It is made for
Maven, but it is possible to use it for non-Maven projects. I find it
better storing even built jarfiles that other projects use on Nexus
rather than in the Subversion repository. We can use a shell script
and the Ant <get> to store and retrieve these jarfiles.
> Nobody complains about storing 'source' images in SVN, and they often
> clutter up the repository more than generated binaries, so I don't think
> the solution is to workaround it by not storing binaries.
Source files are stored in diff format in almost all version control
systems. That means if you change two or three lines in a source file,
only those changes are stored as the next revision.
In most revision control systems, the complete binary is stored --
sometimes in compressed format. That means if you make 1 dozen file
changes build a 500Mb project, the file changes probably take up a few
megabytes at the most while you're storing anywhere between 3 to
6Gigabytes for the built program. Subversion also attempts to store
binaries in "diff" format, but my experience (especially with
compressed file formats like zipped files, jars, jpgs, and gifs, even
the smallest changes end up pretty much storing the entire binary in
the repository.
> Instead I'm hoping svn obliterate will appear sooner rather than later
> and fix this problem for everyone :)
The problem is that this issue is much more difficult to fix than you
might realize.
You make five file changes in revision #4556: one.gif, two.gif,
three.gif, four.txt five.txt. Don't worry about the actual
implementation. Think about these questions.
* I want to remove two.gif at revision #4556. What about the other
four files? Should I be forced to remove the entire revision, or can I
simply remove on revision? What would svn log look like? What if
there's a branch or tag that the revision depends upon? Remember in
Subversion tags live forever even after they're deleted. How is a tag
that uses that particular revision of the file affected?
* If I delete revision two.gif at revision #4556, should these changes
be merged into revision #4557? Probably not. What about four.txt? If I
delete that, should those changes be placed into four.txt in revision
4557? Probably yes.
There are all sorts of philosophical issues that have to be answered
first. I would love to see the ability to remove a particular revision
of any file in Subversion. There's a problem of people accidentally
checking in information (like customer information) that shouldn't be
in the repository. Removing that information is extremely important.
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2258949
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-14 17:41:56 CEST