You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jo Support <jo...@gmail.com> on 2009/09/17 09:18:44 UTC
Delete *for real* from a repository
Hi everybody,
I'm using SVN 1.4.4 on CentOS and I need - for administration purpouse
- to delete *for real* a whole directory from the repository. As
everybody knows, deleting using the "delete" command just adds a new
revision, without freeing space on the disc. I googled my issue,
reading that it's impossible to delete for real something on a
repository, and a filtered dump with a following reimport is needed.
I didn't understand if a dump plus import preserve revision history
for the other files in the repository - I just made one import in my
life, when we migrated from cvs to svn, and - obviously - it started
from revision 1, because of the different type of source repository.
But, I would like to know if updating my SVN (b.e. from 1.4.4 to
1.6.5) there will be a new feature that could let me delete for real
something without dumping and importing.
Thanks in advance
Jo
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395884
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Mark Eichin <ei...@gmail.com>.
Yes, I've used that approach to fix disastrous merges, easier than rolling
back to a previous night's backup... haven't tried it personally since
1.3ish though, I thought there were more bookkeeping files to update.
On Sep 22, 2009 9:22 AM, "Kurt Pruenner" <le...@gmx.at> wrote:
Bolstridge, Andrew wrote: > 2. You accidentally checked in a 1Gb file and
now you want to > re...
Now, I haven't tried it, but shouldn't this be doable by
- taking the repository offline before someone else checks something in
- deleting the last revision(s) under revs and revprops
(assuming you're using a FSFS repo)
- updating current accordingly
- starting the repository again
?
--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
.......It might be written "Mindfuck", but it's spelt "L-A-I-N".......
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397902
To unsubscribe from this discussion, e-mail: [
users-unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2398528
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Kurt Pruenner <le...@gmx.at>.
Bolstridge, Andrew wrote:
> 2. You accidentally checked in a 1Gb file and now you want to
> remove it to save disk space in your backups. This is relatively common
> in SVN as there are no filetype checks by default (you can set your
> client global-ignores, but if a new team member arrives and doesn’t read
> the corporate documentation because he thinks he knows what he’s doing,
> then you can easily get into this problem). In this case, you want to
> delete the file almost as soon as it enters the repository, and you’re
> not concerned about history or any other side effects.
Now, I haven't tried it, but shouldn't this be doable by
- taking the repository offline before someone else checks something in
- deleting the last revision(s) under revs and revprops
(assuming you're using a FSFS repo)
- updating current accordingly
- starting the repository again
?
--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
.......It might be written "Mindfuck", but it's spelt "L-A-I-N".......
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397902
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Nico Kadel-Garcia <nk...@gmail.com>:
> Or typos: "svn copy branches tags" instead of "svn copy
> branches/mybranch-1.0.1 tags" can happen, and causes havoc in the tags
> filetree.
Firstly: nothing really happens until you commit, and if you manage to
commit that without noticing, then... so be it, I'm inclined to say.
Secondly this doesn't need obliterate: the copy doesn't really copy
much, so "svn rm" of what was copied should do the same trick as
obliterate.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2418177
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Sep 18, 2009 at 7:44 AM, Bolstridge, Andrew
<an...@intergraph.com> wrote:
> Obliterate:
>
>
>
> I see 4 reasons for obliterating data in a repository (and this applies to
> every SCM out there).
>
>
>
> 1. You’ve accidentally checked-in the wrong file, or the one that had
> “my boss is a stupid m******** making we work on this s***” that you forgot
> to remove before checkin. Or a password, or confidential data. You’d want to
> take that data out of the repository forever. This doesn’t have to be a true
> obliterate, you can overwrite the data with zeros and the job would still be
> acceptable, or the server could be marked with a ‘no way dude’ flag that
> absolutely prevented anyone from reading that revision.
Or typos: "svn copy branches tags" instead of "svn copy
branches/mybranch-1.0.1 tags" can happen, and causes havoc in the tags
filetree.
>
> 2. You accidentally checked in a 1Gb file and now you want to remove
> it to save disk space in your backups. This is relatively common in SVN as
> there are no filetype checks by default (you can set your client
> global-ignores, but if a new team member arrives and doesn’t read the
> corporate documentation because he thinks he knows what he’s doing, then you
> can easily get into this problem). In this case, you want to delete the file
> almost as soon as it enters the repository, and you’re not concerned about
> history or any other side effects.
And nightly binary build trees. These might benefit from being
mirrored to another repository better suited to holding binaries, but
the difficulty of transferring history to another repository makes
this prohibitively awkward.
>
> 3. You no longer need a file or project in the repository, you can
> delete it, but you will absolutely never ever ever need it again, and so it
> can be permanently removed to free up disk space in the backups.
See above about nightly binary build trees. Also, for old repositories
that used to have things arranged differently, "svn update -r[old
revision] can cause fascinating chaos in such cases.
> 4. You need to archive off ancient revisions to keep your live
> repository working smoothly. This really only applies to corporate orgs
> that have ever-increasing repositories full of data. One day you will want
> to archive all revisions that were checked in over a year ago. These may be
> kept as an archive repo in case someone wants to view them, but you want to
> keep the recent revisions only to make the repo work faster, and your
> current backups backup quicker.
And log commands, and diff commands.
> Now some of these are not really necessary with SVN, #4 for instance, as
> I’ve not found SVN to slow down much even though my repo is 12Gb in size. I
> know we used to archive off VSS dbs, but that’s a whole different bucket of
> manure.
Sounds like you've sensibly kept individual projects in individual
repositories. I've.... had less success encouraging my clients to do
so. They've often preferred to keep all projects in a central
repository, with individual subdirectories for individual projects.
Any one of them can balloon suddenly either with new development work
or check-in policies, especially of binaries, and accidental DVD
commitment has been a serious image.
> #3 and #4 – because svnsync is great at backups, and the backups are
> incremental, neither issue is much of a problem. Disk space might be, but
> even though I complain at the cost of some enterprise hardware (and the
> hoops you have to jump through to be allowed to buy one, those accountants
> have to earn their worth somehow too J), even several gig of data is still
> not an issue nowadays.
True, but svnsync doesn't bring over the server's configuration files.
That has to occur out-of-band. That's what hotcopy is for, but it gets
*SLOW* as accidental commitment errors recur and are very difficult to
flush. And 50 Gig of high-performance 15,000 RPM hard drive is still
expensive, in accumulated server requirements and especially in
off-line backup resources.
> #2 and #1 however.. these are valid reasons for having a svn obliterate
> command. In a perfect world, we’d have something that could archive
> individual or groups of revisions or directories, based on date or revnum.
> Unfortunately, SVN was designed without this feature in mind, and so we’re
> stuck with the problem until the significant investigation and rework gets
> done. It won’t happen until someone figures out how to rewrite a revision’s
> data (as they are all stored as deltas, you need the previous version to
> extract a revision, so you’d need to update your delta based on the previous
> revision-but-one). Also, because some files are cheap copies of others, you
> cannot just delete a file without finding which files were created from it
> and rewriting that file’s initial delta too.
>
>
>
> However, obliterating a newly added file/revision should be easy, and I
> think, cater for most cases where someone wants to obliterate a file for
> privacy reasons. Trouble is, can you guarantee that no-one has made a copy
> of that file in the time between checkin and obliterate?
Yeah. Under CVS, the ancestor to Subversion, you had the concept of
the 'Attic', and could eventually simply delete the directory from the
server. That followed RCS, where it was file-based information, not a
sophisticated database. Procedurally, it does make sense to allow a
flush only by an admin, to be done with caution and the understanding
that "this may cause problems".
> Incidentally I store binaries in my repo, and the binary compression
> algorithm can work wonderfully (a 2mb resource binary can be turned into a
> 100k delta), so I’m not too fussed about that, especially as rebuilding
> versions is truly horrible to contemplate a year down the line and you
> haven’t quite got the correct build dependencies anymore. This is why people
> do have a valid desire to check in binaries.
Oh, yeah, especially because build environments change despite our best efforts.
> So, perhaps it isn’t so difficult to include a form of obliterate that is
> only for admins to run, that might corrupt parts of your repo, but will
> remove a complete file or HEAD revision from the repo completely. A full
> archival mechanism can wait.
It would also seem reasonable to survey the repository for 'copy'
operations on files and directories, and inform the admin of exactly
what files or directories would be impinged. In fact, if svnadmin
could report that information, it might be very helpful indeed.
> Does anyone have links for archiving old revisions from a subversion repo.
> Google isn’t too hot with the word ‘archive’.
Heh. Yeah, keywords don't always work so well.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396411
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Delete *for real* from a repository
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
Obliterate:
I see 4 reasons for obliterating data in a repository (and this applies
to every SCM out there).
1. You've accidentally checked-in the wrong file, or the one that
had "my boss is a stupid m******** making we work on this s***" that you
forgot to remove before checkin. Or a password, or confidential data.
You'd want to take that data out of the repository forever. This doesn't
have to be a true obliterate, you can overwrite the data with zeros and
the job would still be acceptable, or the server could be marked with a
'no way dude' flag that absolutely prevented anyone from reading that
revision.
2. You accidentally checked in a 1Gb file and now you want to
remove it to save disk space in your backups. This is relatively common
in SVN as there are no filetype checks by default (you can set your
client global-ignores, but if a new team member arrives and doesn't read
the corporate documentation because he thinks he knows what he's doing,
then you can easily get into this problem). In this case, you want to
delete the file almost as soon as it enters the repository, and you're
not concerned about history or any other side effects.
3. You no longer need a file or project in the repository, you can
delete it, but you will absolutely never ever ever need it again, and so
it can be permanently removed to free up disk space in the backups.
4. You need to archive off ancient revisions to keep your live
repository working smoothly. This really only applies to corporate orgs
that have ever-increasing repositories full of data. One day you will
want to archive all revisions that were checked in over a year ago.
These may be kept as an archive repo in case someone wants to view them,
but you want to keep the recent revisions only to make the repo work
faster, and your current backups backup quicker.
Now some of these are not really necessary with SVN, #4 for instance, as
I've not found SVN to slow down much even though my repo is 12Gb in
size. I know we used to archive off VSS dbs, but that's a whole
different bucket of manure.
#3 and #4 - because svnsync is great at backups, and the backups are
incremental, neither issue is much of a problem. Disk space might be,
but even though I complain at the cost of some enterprise hardware (and
the hoops you have to jump through to be allowed to buy one, those
accountants have to earn their worth somehow too J), even several gig of
data is still not an issue nowadays.
#2 and #1 however.. these are valid reasons for having a svn obliterate
command. In a perfect world, we'd have something that could archive
individual or groups of revisions or directories, based on date or
revnum. Unfortunately, SVN was designed without this feature in mind,
and so we're stuck with the problem until the significant investigation
and rework gets done. It won't happen until someone figures out how to
rewrite a revision's data (as they are all stored as deltas, you need
the previous version to extract a revision, so you'd need to update your
delta based on the previous revision-but-one). Also, because some files
are cheap copies of others, you cannot just delete a file without
finding which files were created from it and rewriting that file's
initial delta too.
However, obliterating a newly added file/revision should be easy, and I
think, cater for most cases where someone wants to obliterate a file for
privacy reasons. Trouble is, can you guarantee that no-one has made a
copy of that file in the time between checkin and obliterate?
Incidentally I store binaries in my repo, and the binary compression
algorithm can work wonderfully (a 2mb resource binary can be turned into
a 100k delta), so I'm not too fussed about that, especially as
rebuilding versions is truly horrible to contemplate a year down the
line and you haven't quite got the correct build dependencies anymore.
This is why people do have a valid desire to check in binaries.
So, perhaps it isn't so difficult to include a form of obliterate that
is only for admins to run, that might corrupt parts of your repo, but
will remove a complete file or HEAD revision from the repo completely. A
full archival mechanism can wait.
Does anyone have links for archiving old revisions from a subversion
repo. Google isn't too hot with the word 'archive'.
Andy
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396374
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by David Weintraub <qa...@gmail.com>.
One thing I tell users of Subversion is NOT to store binary data in your
repository. If you can build it, don't store it. Obliterating revisions in
text files in Version Control doesn't save a whole lot of space. However,
binaries take up a ton of room -- especially already compressed binaries.
Subversion does to a binary diff, but I am not convinced it saves that much
room. Perforce, for example, doesn't bother with diffing binaries. They
simply compress them.
So, if you're storing binaries in your repository that are either being
built by you or can easily be retrieved elsewhere, the best advice, if you
have Subversion, is to stop. We use Nexus which is a Maven repository
manager and Hudson to store binaries we build. We use Maven and Ant/Ivy to
retrieve these revisions from Nexus when we need them for a build.
Maven is certainly an overkill for this. It is certainly a difficult piece
of software to learn, and documentation is weak, but it does allow us to
version binary files outside of our Subversion repository.
There's a lot of difficulty in an "svn obliterate' command. For example, I
changed a dozen of files in revision 1234 including foo.java. I obliterate
revision 1234 of foo.java, what does the rest of revision 1234 now look
like. Does it contain foo.java 1233 or foo.java 1235? What if I did a copy
of revision 1234 to a tag or branch? How would that be affected?
John Loyd refers to himself as an "ignostic". He refuses to be drawn into a
debate about God's existence until all the terms are well defined. We have a
similar issue with an "svn obliterate" command. We know what we sort of
want, but we need to know exactly how it works and what it should do in each
and every circumstance.
I have found that as long as I keep binary files out of Subversion, I really
don't need obliterate. But, developers aren't thrilled about that. They find
it easier if pre-built revisions are stored in Subversion. It's nice to be
able to pull a Jarfile out of Subversion rather than depend upon Ant/Ivy to
do it for you. Sometimes you build specific "core" jars that you simply
don't want to version via a release repository, but want to share between
projects.
There are also times when it is extremely important to completely remove a
particular revision of a file. In Financial systems, it is quite common for
a developer to check in a file and then discover that customer proprietary
data was included. Because of this, I don't recommend Subversion in certain
situations.
Subversion does need an obliterate command, but it will be very difficult to
implement. By the way, when I was using Perforce at one site, I think I used
the obliterate command maybe about a half dozen times in the two years I was
there. Most of that time, it was a developer who accidentally checked in the
wrong version of a file. In Subversion, you'd simply tell them to check in
the correct revision. (Because of my experience with Subversion, we didn't
store releases in Perforce, so most of what we stored were just text files.
Therefore, we didn't have to purge our repository from obsolete releases).
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396053
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Les Mikesell <le...@gmail.com>.
Stefan Sperling wrote:
> On Thu, Sep 17, 2009 at 09:31:46AM -0500, Hyrum K. Wright wrote:
>> On Sep 17, 2009, at 8:39 AM, Stefan Sperling wrote:
>>
>>> On Thu, Sep 17, 2009 at 03:18:31PM +0200, Jo Support wrote:
>>>> ...and, I think that powerful and cheaper technology should not
>>>> excuse
>>>> careless software development.
>>> Not having obliterate is not "careless".
>>> It's *not* an easy problem.
>> I don't think this was a knock on Subversion. I think he was
>> referring to the fact that having version control should not excuse
>> users of said software into being foolhardy.
>
> Oh. Then I apologise, having missed the context.
Well I'll repeat it in the context of an unrealistic design, then, and
add add that the longer additional development continues to make the
assumption that mistakes never happen and never need to be
administratively corrected the harder it will be to fix.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396048
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Sep 17, 2009 at 09:31:46AM -0500, Hyrum K. Wright wrote:
>
> On Sep 17, 2009, at 8:39 AM, Stefan Sperling wrote:
>
> >On Thu, Sep 17, 2009 at 03:18:31PM +0200, Jo Support wrote:
> >>...and, I think that powerful and cheaper technology should not
> >>excuse
> >>careless software development.
> >
> >Not having obliterate is not "careless".
> >It's *not* an easy problem.
>
> I don't think this was a knock on Subversion. I think he was
> referring to the fact that having version control should not excuse
> users of said software into being foolhardy.
Oh. Then I apologise, having missed the context.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396041
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Sep 17, 2009, at 8:39 AM, Stefan Sperling wrote:
> On Thu, Sep 17, 2009 at 03:18:31PM +0200, Jo Support wrote:
>> ...and, I think that powerful and cheaper technology should not
>> excuse
>> careless software development.
>
> Not having obliterate is not "careless".
> It's *not* an easy problem.
I don't think this was a knock on Subversion. I think he was
referring to the fact that having version control should not excuse
users of said software into being foolhardy.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396023
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Sep 17, 2009 at 03:18:31PM +0200, Jo Support wrote:
> ...and, I think that powerful and cheaper technology should not excuse
> careless software development.
Not having obliterate is not "careless".
It's *not* an easy problem.
> I don't want to keep tons of garbage
> just because of high-capacity-cheap-disks - or - stop a service
> because cleaning my repository takes hours of work (dumping, cleaning
> and importing hundreds GBs of data). Ok, got it, I will spend my
> freetime looking on how develop "svn obliterate" ^^
Julian Foad is working on the specification and has made great
progress: http://svn.collab.net/repos/svn/trunk/notes/obliterate/
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396008
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Jo Support <jo...@gmail.com>.
On Thu, Sep 17, 2009 at 2:54 PM, Les Mikesell <le...@gmail.com> wrote:
> Bolstridge, Andrew wrote:
>>> -----Original Message-----
>>> From: Ryan Schmidt [mailto:subversion-2009b@ryandesign.com]
>>> Sent: Thursday, September 17, 2009 11:59 AM
>>> To: Jo Support
>>> Cc: users@subversion.tigris.org
>>> Subject: Re: Delete *for real* from a repository
>>>
>> [snip]
>>> ... Disk is cheap ...
>>
>> You've never bought a HP 300Gb hot-swap 15k SCSI drive then :)
>>
>> (http://www.dabs.com/products/hp-300gb-pluggable-ultra-320-scsi-5CJT.htm
>> l?prev=34Y7)
>
> Not to mention the tapes holding daily backups, the service taking them offsite,
> or the time/effort it takes to grow a raid and filesystem every time it runs
> out of space.
>
...and, I think that powerful and cheaper technology should not excuse
careless software development. I don't want to keep tons of garbage
just because of high-capacity-cheap-disks - or - stop a service
because cleaning my repository takes hours of work (dumping, cleaning
and importing hundreds GBs of data). Ok, got it, I will spend my
freetime looking on how develop "svn obliterate" ^^
> --
> Les Mikesell
> lesmikesell@gmail.com
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395993
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396000
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Les Mikesell <le...@gmail.com>.
Bolstridge, Andrew wrote:
>> -----Original Message-----
>> From: Ryan Schmidt [mailto:subversion-2009b@ryandesign.com]
>> Sent: Thursday, September 17, 2009 11:59 AM
>> To: Jo Support
>> Cc: users@subversion.tigris.org
>> Subject: Re: Delete *for real* from a repository
>>
> [snip]
>> ... Disk is cheap ...
>
> You've never bought a HP 300Gb hot-swap 15k SCSI drive then :)
>
> (http://www.dabs.com/products/hp-300gb-pluggable-ultra-320-scsi-5CJT.htm
> l?prev=34Y7)
Not to mention the tapes holding daily backups, the service taking them offsite,
or the time/effort it takes to grow a raid and filesystem every time it runs
out of space.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395993
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Delete *for real* from a repository
Posted by Bob Archer <bo...@amsi.com>.
> > -----Original Message-----
> > From: Ryan Schmidt [mailto:subversion-2009b@ryandesign.com]
> > Sent: Thursday, September 17, 2009 11:59 AM
> > To: Jo Support
> > Cc: users@subversion.tigris.org
> > Subject: Re: Delete *for real* from a repository
> >
> [snip]
> >
> > ... Disk is cheap ...
>
> You've never bought a HP 300Gb hot-swap 15k SCSI drive then :)
>
> (http://www.dabs.com/products/hp-300gb-pluggable-ultra-320-scsi-
> 5CJT.htm
> l?prev=34Y7)
I didn't even look at your link. But, relative to a developers time hardware is cheap. Jeff Attwood has a good blog post about this recently.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396024
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Delete *for real* from a repository
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2009b@ryandesign.com]
> Sent: Thursday, September 17, 2009 11:59 AM
> To: Jo Support
> Cc: users@subversion.tigris.org
> Subject: Re: Delete *for real* from a repository
>
[snip]
>
> ... Disk is cheap ...
You've never bought a HP 300Gb hot-swap 15k SCSI drive then :)
(http://www.dabs.com/products/hp-300gb-pluggable-ultra-320-scsi-5CJT.htm
l?prev=34Y7)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395981
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 17, 2009, at 05:26, Jo Support wrote:
> I have one last noob question: it
> is possible - almost certain - that my repository is full with hidden
> (deleted) path that I would like to get rid of too. I don't remind
> where and when I deleted things in the labyrinth of directories inside
> my repo, so I would like to know if there is an option for the dump
> filter to exclude all files/dirs that on the head are deleted/hidden.
> I read the article suggested by Nick (thanks!) but I've missed (or I
> didn't understand) something about this issue.
No, there isn't such an option. You would have to manually find them
all yourself. It's almost certainly cheaper to buy a bigger disk, if
necessary, than to spend time tracking down things to obliterate in
your repository's history, especially since rearranging repository
history like that involves quite a bit of discomfort, including
requiring everyone who had a working copy checked out to throw it away
and get a new one. Disk is cheap, which is perhaps one reason why "svn
obliterate" is still unimplemented.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395921
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Jo Support <jo...@gmail.com>.
Thanks for the replies!
I have one last noob question: it
is possible - almost certain - that my repository is full with hidden
(deleted) path that I would like to get rid of too. I don't remind
where and when I deleted things in the labyrinth of directories inside
my repo, so I would like to know if there is an option for the dump
filter to exclude all files/dirs that on the head are deleted/hidden.
I read the article suggested by Nick (thanks!) but I've missed (or I
didn't understand) something about this issue.
On Thu, Sep 17, 2009 at 12:06 PM, Bolstridge, Andrew
<an...@intergraph.com> wrote:
>
>
>> -----Original Message-----
>> From: Jo Support [mailto:jo.support@gmail.com]
>> Sent: Thursday, September 17, 2009 10:19 AM
>> To: users@subversion.tigris.org
>> Subject: Delete *for real* from a repository
>>
>> Hi everybody,
>>
>> I'm using SVN 1.4.4 on CentOS and I need - for administration purpouse
>> - to delete *for real* a whole directory from the repository. As
>> everybody knows, deleting using the "delete" command just adds a new
>> revision, without freeing space on the disc. I googled my issue,
>> reading that it's impossible to delete for real something on a
>> repository, and a filtered dump with a following reimport is needed.
>>
>> I didn't understand if a dump plus import preserve revision history
>> for the other files in the repository - I just made one import in my
>> life, when we migrated from cvs to svn, and - obviously - it started
>> from revision 1, because of the different type of source repository.
>>
>> But, I would like to know if updating my SVN (b.e. from 1.4.4 to
>> 1.6.5) there will be a new feature that could let me delete for real
>> something without dumping and importing.
>>
>
> No, "svn obliterate" is still not implemented. Currently (and for the
> foreseeable future) your only hope is to either a) use
> svndump+filter+load, b) write the obliterate code for svn yourself.
>
> Dumping the repo will preserve all revision history, with the exception
> of the filtered revisions. If you're concerned how it will work, dump
> your repo to a test and leave the real one running while you experiment
> with it. Filtering out revisions may affect the revision numbers, so if
> you use them, you might want to check.
>
> You can also load the repo into a more up-to-date SVN version, which is
> well recommended anyway.
>
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395907
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Delete *for real* from a repository
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
> -----Original Message-----
> From: Jo Support [mailto:jo.support@gmail.com]
> Sent: Thursday, September 17, 2009 10:19 AM
> To: users@subversion.tigris.org
> Subject: Delete *for real* from a repository
>
> Hi everybody,
>
> I'm using SVN 1.4.4 on CentOS and I need - for administration purpouse
> - to delete *for real* a whole directory from the repository. As
> everybody knows, deleting using the "delete" command just adds a new
> revision, without freeing space on the disc. I googled my issue,
> reading that it's impossible to delete for real something on a
> repository, and a filtered dump with a following reimport is needed.
>
> I didn't understand if a dump plus import preserve revision history
> for the other files in the repository - I just made one import in my
> life, when we migrated from cvs to svn, and - obviously - it started
> from revision 1, because of the different type of source repository.
>
> But, I would like to know if updating my SVN (b.e. from 1.4.4 to
> 1.6.5) there will be a new feature that could let me delete for real
> something without dumping and importing.
>
No, "svn obliterate" is still not implemented. Currently (and for the
foreseeable future) your only hope is to either a) use
svndump+filter+load, b) write the obliterate code for svn yourself.
Dumping the repo will preserve all revision history, with the exception
of the filtered revisions. If you're concerned how it will work, dump
your repo to a test and leave the real one running while you experiment
with it. Filtering out revisions may affect the revision numbers, so if
you use them, you might want to check.
You can also load the repo into a more up-to-date SVN version, which is
well recommended anyway.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395903
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Delete *for real* from a repository
Posted by Bob Archer <bo...@amsi.com>.
> Bob Archer wrote:
> >> I'm using SVN 1.4.4 on CentOS and I need - for administration
> purpouse
> >> - to delete *for real* a whole directory from the repository. As
> >> everybody knows, deleting using the "delete" command just adds a new
> >> revision, without freeing space on the disc. I googled my issue,
> >> reading that it's impossible to delete for real something on a
> >> repository, and a filtered dump with a following reimport is needed.
> >
> > With the current version you need to think of the repository as
> create/update only and plan for this in capacity planning. The bottom
> line is that things are going to be added to your repository that you
> don't want in there. If you go and dump/load every time this happens
> you are going to drive yourself crazy. You just have to be ok with it.
> >
> > There are many requests to add this, but frankly I consider it a low
> priority... at least for me. To others it is a high priority. I would
> rather see the developers would on stuff like WC-ng and better history
> for move/renames and perhaps better branch/merge functions like brining
> in some of the features of the svncopy.pl utility.
>
> Something that can only grow infinitely just does not seem well
> designed
> for real world use, even if in practice it often works out for a while.
>
Tell google that. They tell me I never need to delete email again and my mail space will grow infinitely. Think about how much a 1TB hard drive cost 3 or 4 years ago and how much it costs today.
Anyway... you still can trim your repo. I just don't think doing it every time someone is human and puts a file into it that really shouldn't be there.
However, a yearly or maybe even every other year dump/load to reduce the size of your repository is certainly reasonable. Yes, it would be nice to have a tool to do this faster than a dump/load. Yes, I would still put that tool at the bottom of my "wish list".
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396033
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Les Mikesell <le...@gmail.com>.
Florian Weimer wrote:
> * Les Mikesell:
>
>> Something that can only grow infinitely just does not seem well designed
>> for real world use, even if in practice it often works out for a while.
>
> Are there repositories out there which regularly prune history due to
> size concerns? I haven't seen a single public repository doing that,
> even with systems where this is somewhat easier than with Subversion.
Pruning 'regularly' isn't quite the point. If you need that you are
doing something wrong regularly. Wanting the ability to fix something
that is done wrong once in a while is sort of like wanting to know that
your building has emergency exits (i.e. is properly designed for real
world events).
> On the other hand, if you could prune history easily, you'd open up
> many additional scenarios (using Subversion as a replacement for an
> ordinary distributed file system etc.). But such applications aren't
> typically in the focus of version control systems.
Yes, I would love to be able to use subversion as a versioning file
system. It would be incredibly useful, especially if you could
concurrently use all of the existing client tools.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396079
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Andy Levy <an...@gmail.com>.
On Thu, Sep 17, 2009 at 11:32, Florian Weimer <fw...@bfk.de> wrote:
> * Les Mikesell:
>
>> Something that can only grow infinitely just does not seem well designed
>> for real world use, even if in practice it often works out for a while.
>
> Are there repositories out there which regularly prune history due to
> size concerns? I haven't seen a single public repository doing that,
> even with systems where this is somewhat easier than with Subversion.
>
> On the other hand, if you could prune history easily, you'd open up
> many additional scenarios (using Subversion as a replacement for an
> ordinary distributed file system etc.). But such applications aren't
> typically in the focus of version control systems.
If one could easily prune history, my auditors & management would
start having major concerns about our use of Subversion and throw even
more controls on things than we already have.
My repositories are trivially small compared to the 128GB database
which has, amongst its many tables, a single table that consumes
120GB. No one *ever* talks about "pruning" that data.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396074
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Florian Weimer <fw...@bfk.de>.
* Les Mikesell:
> Something that can only grow infinitely just does not seem well designed
> for real world use, even if in practice it often works out for a while.
Are there repositories out there which regularly prune history due to
size concerns? I haven't seen a single public repository doing that,
even with systems where this is somewhat easier than with Subversion.
On the other hand, if you could prune history easily, you'd open up
many additional scenarios (using Subversion as a replacement for an
ordinary distributed file system etc.). But such applications aren't
typically in the focus of version control systems.
--
Florian Weimer <fw...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396063
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Les Mikesell <le...@gmail.com>.
Bob Archer wrote:
>> I'm using SVN 1.4.4 on CentOS and I need - for administration purpouse
>> - to delete *for real* a whole directory from the repository. As
>> everybody knows, deleting using the "delete" command just adds a new
>> revision, without freeing space on the disc. I googled my issue,
>> reading that it's impossible to delete for real something on a
>> repository, and a filtered dump with a following reimport is needed.
>
> With the current version you need to think of the repository as create/update only and plan for this in capacity planning. The bottom line is that things are going to be added to your repository that you don't want in there. If you go and dump/load every time this happens you are going to drive yourself crazy. You just have to be ok with it.
>
> There are many requests to add this, but frankly I consider it a low priority... at least for me. To others it is a high priority. I would rather see the developers would on stuff like WC-ng and better history for move/renames and perhaps better branch/merge functions like brining in some of the features of the svncopy.pl utility.
Something that can only grow infinitely just does not seem well designed
for real world use, even if in practice it often works out for a while.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396029
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Les Mikesell <le...@gmail.com>.
russ@vshift.com wrote:
> This is also probably one of the major reasons that most developers are switching to GIT... SVN came out to be from the ground up redesign of CVS and now GIT seems to have come out as a redesign of SVN. Looks like if things don't shape up soon with the SVN development, GIT will push SVN into obscurity.
No, GIT isn't a 'redesign' of SVN, it's an entirely different philosophy
based on the idea that central control is evil. I'm not sure I see
everyone buying into that. And I don't think the GUI tools have caught
up yet either.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396073
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Les Mikesell <le...@gmail.com>.
Nico Kadel-Garcia wrote:
> >
> See above as an example of one of its features. I find git to be
> easier to secure, and not prone to the "store passwords in clear-text"
> problem of Subversion's UNIX and Linux default clients. It also
> permits off-line changes to occur, and to be stored locally. For
> systems (such as configuration files for complex software that may be
> offsite, especially security or network configuration files), this is
> very useful.
If I want to steal your code and I have access to a disk containing a
GIT repostiory, don't I already have the whole thing without additional
need for a password?
With subversion you can at least secure different parts of the
repository so you need different passwords to access them.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396184
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
David Weintraub wrote:
> However, I find major problems with GIT when you are working in a commercial
> environment. First of all, each copy of the GIT repository requires a
> particular person to be the gatekeeper whether or not to accept changes in
> their copy. That means that person is responsible for merging all changes
> into that copy of the repository. The last place which used Git made me, the
> SCM who is not a developer, the person responsible for handling all the
> merging since the developers didn't want to do it themselves. Hilarity
> ensued.
I see no such problem. All git clients can have a reference to a
'master' repostiroy, against which their changes can be compared and
merges made locally, and in fact can have configured references to
secondary and tertiary repositories for particular features. I set up
exactly this last spring for someone who works on his laptop going to
and from work, and with various contributors, so that each of us could
do our work remotely, *record changes remotely as individual changes*,
push them back to our development "branches" on the centralized
repository, and the project lead could approve or reject individual
sets of changes to the master.
> I can see why GIT is popular and why Linux uses it, but I don't see a
> distributed repository as the bright shiny future of revision control.
See above as an example of one of its features. I find git to be
easier to secure, and not prone to the "store passwords in clear-text"
problem of Subversion's UNIX and Linux default clients. It also
permits off-line changes to occur, and to be stored locally. For
systems (such as configuration files for complex software that may be
offsite, especially security or network configuration files), this is
very useful.
The integrated tag-signature utility is very useful for code releases:
so is the much, much better integrated security model of the dedicated
shell for SSH access, rather than the more complex and fragile
svn+ssh. If there weren't such a legacy of old CVS and now Subversion
projects, I'd have discarded Subversion last spring.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396160
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by David Weintraub <qa...@gmail.com>.
Many people are jumping on GIT because it's what Linux uses and if Linux
uses it, it must be cool. What people don't understand is that Linux has a
good reason not to use something like Subversion.
Linux has a hierarchy of thousands of contributors. Giving and vetting each
one would be almost impossible. So, GIT works out pretty well because each
copy of the GIT repository has a gatekeeper who is responsible for that
revision. For example, if I want to make a change in Linux, I could checkout
the root copy of the repository and try to submit a change, but the change
will simply be rejected because I am not a trusted contributor at that
level.
Instead, I find a friend who is working on Linux and check out from his copy
of the repository. My friend will accept my changes and then submit their
changes with mine to the copy of the repository they used. As this gets
filtered up the line, my change might eventually make it into the official
release.
However, I find major problems with GIT when you are working in a commercial
environment. First of all, each copy of the GIT repository requires a
particular person to be the gatekeeper whether or not to accept changes in
their copy. That means that person is responsible for merging all changes
into that copy of the repository. The last place which used Git made me, the
SCM who is not a developer, the person responsible for handling all the
merging since the developers didn't want to do it themselves. Hilarity
ensued.
Another problem is what I call the ClearCase problem. In ClearCase, each
developer gets their own branch for development, and the developers like it
because they can easily make their changes without worrying about the
constant updates to the source code other developers make. Unfortunately, it
is very easy to forget to submit your work on a regular basis. Developers
started changing bigger and bigger chunks of code and then submitting those
changes right before a release deadline. Forcing all developers to work on
the same branch makes each developer more careful about their code, and
their changes. Add a continuous build engine, mix, and serve.
This ClearCase problem isn't an issue with the open source because there is
no real deadline pressure. In GIT, if someone is making a particular change,
doesn't keep up to date with the rest of the changes in the source tree,
then submits their changes, that changes can easily be rejected. When you
promised paying customers that your software will have feature "X" by the
end of the month, and the person who is working on feature "X" submits the
changes on the 27th of the month, you have to accept their changes.
I can see why GIT is popular and why Linux uses it, but I don't see a
distributed repository as the bright shiny future of revision control.
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396151
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Sep 17, 2009, at 10:08 AM, russ@vshift.com wrote:
> This is also probably one of the major reasons that most developers
> are switching to GIT...
I'm interested in what the definition of "most" is, and where you get
the data to back up such a statement. *Many* large software
development shops deploy Subversion, and I have yet to see a company
with 3k or 5k developers move to a distributed system such as git. My
experience could be limited, though, which is why I'm interested to
hear your sources.
(Yes, I know, I'm ugly and stupid for saying the above. I'm not
trying to start a VC flame war, and I know that Subversion has it's
warts, but I still think it's a decent version control system.)
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396068
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by Andy Levy <an...@gmail.com>.
On Thu, Sep 17, 2009 at 11:08, <ru...@vshift.com> wrote:
> This is also probably one of the major reasons that most developers are switching to GIT... SVN came out to be from the ground up redesign of CVS and now GIT seems to have come out as a redesign of SVN. Looks like if things don't shape up soon with the SVN development, GIT will push SVN into obscurity.
I won't even consider leaving SVN for GIT until GIT supports Windows
as easily as SVN does.
> -----Original Message-----
> From: Tony Sweeney <ts...@omnifone.com>
>
> Date: Thu, 17 Sep 2009 15:56:08
> To: Bob Archer<bo...@amsi.com>; Jo Support<jo...@gmail.com>; <us...@subversion.tigris.org>
> Subject: RE: Delete *for real* from a repository
>
>
>> -----Original Message-----
>> From: Bob Archer [mailto:bob.archer@amsi.com]
>> Sent: 17 September 2009 15:31
>> To: Jo Support; users@subversion.tigris.org
>> Subject: RE: Delete *for real* from a repository
>>
>> > I'm using SVN 1.4.4 on CentOS and I need - for
>> administration purpouse
>> > - to delete *for real* a whole directory from the repository. As
>> > everybody knows, deleting using the "delete" command just
>> adds a new
>> > revision, without freeing space on the disc. I googled my issue,
>> > reading that it's impossible to delete for real something on a
>> > repository, and a filtered dump with a following reimport is needed.
>>
>> With the current version you need to think of the repository
>> as create/update only and plan for this in capacity planning.
>> The bottom line is that things are going to be added to your
>> repository that you don't want in there. If you go and
>> dump/load every time this happens you are going to drive
>> yourself crazy. You just have to be ok with it.
>>
>> There are many requests to add this, but frankly I consider
>> it a low priority... at least for me. To others it is a high
>> priority. I would rather see the developers would on stuff
>> like WC-ng and better history for move/renames and perhaps
>> better branch/merge functions like brining in some of the
>> features of the svncopy.pl utility.
>
> Just for perspective, Perforce has had an obliterate command since at
> least 1997, and the ability to obliterate files was one of the first and
> most heavily voted for system enhancement requests (the first commercial
> release of Perforce was in 1996). When you have paying customers, you
> tend to implement what they want.
>
> Tony.
>
>>
>> BOb
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&
>> dsMessageId=2396022
>>
>> To unsubscribe from this discussion, e-mail:
>> [users-unsubscribe@subversion.tigris.org].
>>
>>______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit
>> http://www.messagelabs.com/email
>>______________________________________________________________________
>>
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396035
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396046
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396056
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Delete *for real* from a repository
Posted by ru...@vshift.com.
This is also probably one of the major reasons that most developers are switching to GIT... SVN came out to be from the ground up redesign of CVS and now GIT seems to have come out as a redesign of SVN. Looks like if things don't shape up soon with the SVN development, GIT will push SVN into obscurity.
Russ
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Tony Sweeney <ts...@omnifone.com>
Date: Thu, 17 Sep 2009 15:56:08
To: Bob Archer<bo...@amsi.com>; Jo Support<jo...@gmail.com>; <us...@subversion.tigris.org>
Subject: RE: Delete *for real* from a repository
> -----Original Message-----
> From: Bob Archer [mailto:bob.archer@amsi.com]
> Sent: 17 September 2009 15:31
> To: Jo Support; users@subversion.tigris.org
> Subject: RE: Delete *for real* from a repository
>
> > I'm using SVN 1.4.4 on CentOS and I need - for
> administration purpouse
> > - to delete *for real* a whole directory from the repository. As
> > everybody knows, deleting using the "delete" command just
> adds a new
> > revision, without freeing space on the disc. I googled my issue,
> > reading that it's impossible to delete for real something on a
> > repository, and a filtered dump with a following reimport is needed.
>
> With the current version you need to think of the repository
> as create/update only and plan for this in capacity planning.
> The bottom line is that things are going to be added to your
> repository that you don't want in there. If you go and
> dump/load every time this happens you are going to drive
> yourself crazy. You just have to be ok with it.
>
> There are many requests to add this, but frankly I consider
> it a low priority... at least for me. To others it is a high
> priority. I would rather see the developers would on stuff
> like WC-ng and better history for move/renames and perhaps
> better branch/merge functions like brining in some of the
> features of the svncopy.pl utility.
Just for perspective, Perforce has had an obliterate command since at
least 1997, and the ability to obliterate files was one of the first and
most heavily voted for system enhancement requests (the first commercial
release of Perforce was in 1996). When you have paying customers, you
tend to implement what they want.
Tony.
>
> BOb
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&
> dsMessageId=2396022
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe@subversion.tigris.org].
>
>______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit
> http://www.messagelabs.com/email
>______________________________________________________________________
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396035
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396046
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Delete *for real* from a repository
Posted by Tony Sweeney <ts...@omnifone.com>.
> -----Original Message-----
> From: Bob Archer [mailto:bob.archer@amsi.com]
> Sent: 17 September 2009 15:31
> To: Jo Support; users@subversion.tigris.org
> Subject: RE: Delete *for real* from a repository
>
> > I'm using SVN 1.4.4 on CentOS and I need - for
> administration purpouse
> > - to delete *for real* a whole directory from the repository. As
> > everybody knows, deleting using the "delete" command just
> adds a new
> > revision, without freeing space on the disc. I googled my issue,
> > reading that it's impossible to delete for real something on a
> > repository, and a filtered dump with a following reimport is needed.
>
> With the current version you need to think of the repository
> as create/update only and plan for this in capacity planning.
> The bottom line is that things are going to be added to your
> repository that you don't want in there. If you go and
> dump/load every time this happens you are going to drive
> yourself crazy. You just have to be ok with it.
>
> There are many requests to add this, but frankly I consider
> it a low priority... at least for me. To others it is a high
> priority. I would rather see the developers would on stuff
> like WC-ng and better history for move/renames and perhaps
> better branch/merge functions like brining in some of the
> features of the svncopy.pl utility.
Just for perspective, Perforce has had an obliterate command since at
least 1997, and the ability to obliterate files was one of the first and
most heavily voted for system enhancement requests (the first commercial
release of Perforce was in 1996). When you have paying customers, you
tend to implement what they want.
Tony.
>
> BOb
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&
> dsMessageId=2396022
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe@subversion.tigris.org].
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit
> http://www.messagelabs.com/email
> ______________________________________________________________________
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396035
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Delete *for real* from a repository
Posted by Bob Archer <bo...@amsi.com>.
> I'm using SVN 1.4.4 on CentOS and I need - for administration purpouse
> - to delete *for real* a whole directory from the repository. As
> everybody knows, deleting using the "delete" command just adds a new
> revision, without freeing space on the disc. I googled my issue,
> reading that it's impossible to delete for real something on a
> repository, and a filtered dump with a following reimport is needed.
With the current version you need to think of the repository as create/update only and plan for this in capacity planning. The bottom line is that things are going to be added to your repository that you don't want in there. If you go and dump/load every time this happens you are going to drive yourself crazy. You just have to be ok with it.
There are many requests to add this, but frankly I consider it a low priority... at least for me. To others it is a high priority. I would rather see the developers would on stuff like WC-ng and better history for move/renames and perhaps better branch/merge functions like brining in some of the features of the svncopy.pl utility.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396022
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].