David Weintraub 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.
Can you comment on how it might work for non-java projects? For
example, common libraries for other c or c++ projects or deployable
executables - probably would be managed by Hudson, though.
>> 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.
The same philosophical issues apply to doing it the hard way with dump
and filter. It's hard even to split things up keeping the history if
you have moved them around in the repository.
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2260491
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-14 19:22:40 CEST