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...@gmail.com on 2006/03/15 23:20:07 UTC
Making a file in the working directory not be managed by Subversion any more
What is the best way to make a file that has been managed by Subversion not
be managed any more?
For instance, if a file got accidently added to the repository, how to
remove it from there without removing
it from the working directory? Is there a way to "officially" drop it?
(I believe it is impossible to remove all previous versions without
re-building the repository, but what
about simply removing it from now on?)
Re: Making a file in the working directory not be managed by Subversion any more
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 21, 2006, at 22:20, Les Mikesell wrote:
> On Mon, 2006-08-21 at 17:21 +0200, Ryan Schmidt wrote:
>
>> The second is what has often been called "svnadmin obliterate". There
>> is this feature request:
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=516
>>
>> I understand that this is extremely difficult, not just to implement,
>> since Subversion is specifically designed to retain all history, so
>> making it suddenly forget some of that is counter to its very nature,
>> but also difficult to define what exactly is meant. Are we
>> obliterating a single item in the repository at a single revision? Or
>> all revisions of this item throughout time?
>
> Assume that there is something in the repository that could make you
> or your company the target of a very expensive lawsuit if anyone is
> ever able to retrieve it and read it. In the US at least that doesn't
> take very much, so it is likely to be a common problem.
>
>> What if it moved or was
>> renamed? What if it was copied? Are the copies removed too? Even if
>> they've subsequently changed substantially or completely? It's a
>> complicated issue, which is why it's not done yet. In the mean time,
>> you have the "svnadmin dump" / "svndumpfilter" / "svnadmin load"
>> alternative, which is deliberately cumbersome because as mentioned
>> Subversion's goal is to retain all history.
>
> I agree that it should be an admin-only operation but making it
> difficult is just short-sighted. Everyone is going to accumulate
> junk (or worse) eventually.
Well, maybe "deliberately" was the wrong word. I certainly don't
think the Subversion team is intending to make anything difficult on
anybody. Rather, as explained briefly above and also in the bug,
because Subversion, as any good revision control system, is
specifically designed to keep everything, making it suddenly forget
specific somethings is difficult to do. There are many open
Subversion issues and feature requests, and only a limited number of
Subversion developers, who have to prioritize what tasks they work on
now and which ones they leave for later, using a number of criteria.
Priorities so far have apparently been such that this feature has not
yet been implemented.
I don't think this is unreasonable either. The developers have to
start somewhere to eventually get to software that works. Beginning
from the standpoint that a version control system should keep all
data, and implementing that, seems reasonable. That some people need
to be able to permanently kill data from the repository also seems
plausible to me. The dump / filter / load cycle currently enables
that to occur, even if it's a bit difficult currently. Proper
education of committers is necessary to make sure they understand the
permanency of what they're committing, so that the frequency of
mistakes necessitating the dump / filter / load cycle can be reduced.
Hopefully one day in the future an admin will be more easily able to
obliterate parts of the repository. It's just not there yet.
By not using a single repository, and instead using multiple
repositories, separated based on criteria that make sense to you (by
project, by department, etc.) you can reduce the impact of taking the
repository offline for a dump / filter / load cycle, and reduce the
time such a cycle takes, since there will be less data to dump,
filter and load.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Making a file in the working directory not be managed by
Subversion any more
Posted by Les Mikesell <le...@gmail.com>.
On Mon, 2006-08-21 at 17:21 +0200, Ryan Schmidt wrote:
> The second is what has often been called "svnadmin obliterate". There
> is this feature request:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=516
>
> I understand that this is extremely difficult, not just to implement,
> since Subversion is specifically designed to retain all history, so
> making it suddenly forget some of that is counter to its very nature,
> but also difficult to define what exactly is meant. Are we
> obliterating a single item in the repository at a single revision? Or
> all revisions of this item throughout time?
Assume that there is something in the repository that could make you
or your company the target of a very expensive lawsuit if anyone is
ever able to retrieve it and read it. In the US at least that doesn't
take very much, so it is likely to be a common problem.
> What if it moved or was
> renamed? What if it was copied? Are the copies removed too? Even if
> they've subsequently changed substantially or completely? It's a
> complicated issue, which is why it's not done yet. In the mean time,
> you have the "svnadmin dump" / "svndumpfilter" / "svnadmin load"
> alternative, which is deliberately cumbersome because as mentioned
> Subversion's goal is to retain all history.
I agree that it should be an admin-only operation but making it
difficult is just short-sighted. Everyone is going to accumulate
junk (or worse) eventually.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Making a file in the working directory not be managed by Subversion any more
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 20, 2006, at 10:42, johann petrak wrote:
> I think an "unversion" command should be a standard part of
> subversion: it can easily
> happen that one puts unwanted files or even directories in the
> repository by accident
> when a big project is initially added.
> It would probably be best to have a command that by default does
> what the workaround
> of copy/svn delete/copyback does, with a --force option that in
> addition removes the complete
> history of the file from the repository (this would be good to have
> if by accident very large
> files or directories got added).
Well these are two very different operations. The first is the one
that has the workaround described and is probably easy to implement,
should it be decided that it's worth it. (I'm guessing it probably
isn't worth it at this point, since the workaround is so simple and
easy, and it would take time to implement and test, and that's time
that could be better spent on more-important missing features for
which no workaround exists.)
The second is what has often been called "svnadmin obliterate". There
is this feature request:
http://subversion.tigris.org/issues/show_bug.cgi?id=516
I understand that this is extremely difficult, not just to implement,
since Subversion is specifically designed to retain all history, so
making it suddenly forget some of that is counter to its very nature,
but also difficult to define what exactly is meant. Are we
obliterating a single item in the repository at a single revision? Or
all revisions of this item throughout time? What if it moved or was
renamed? What if it was copied? Are the copies removed too? Even if
they've subsequently changed substantially or completely? It's a
complicated issue, which is why it's not done yet. In the mean time,
you have the "svnadmin dump" / "svndumpfilter" / "svnadmin load"
alternative, which is deliberately cumbersome because as mentioned
Subversion's goal is to retain all history. I say "svnadmin
obliterate" above and not "svn obliterate" because since obliteration
would permanently destroy data, it is definitely not a command a
regular user should be able to do, and thus should be reserved for
repository administrators.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Making a file in the working directory not be managed by Subversion any more
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: johann.petrak@gmail.com
To: Donald H Locker
Cc: users@subversion.tigris.org
Sent: Sunday, August 20, 2006 4:42 AM
Subject: Re: Making a file in the working directory not be managed by Subversion any more
I think an "unversion" command should be a standard part of subversion: it can easily
happen that one puts unwanted files or even directories in the repository by accident
when a big project is initially added.
It would probably be best to have a command that by default does what the workaround
of copy/svn delete/copyback does, with a --force option that in addition removes the complete
history of the file from the repository (this would be good to have if by accident very large
files or directories got added).
I think what you're looking for is referred to as "obliterate", to eliminate a file and all traces of it in the repository. Adding large files and directories is inevitable in a group project. Somebody's going to import the original project software directory called "project-1.2.3" into trunk, and you'll wind up with "trunk/project-1.2.3" instead of just the files in trunk. That class of mistake happens all the time, and it's currently pretty painful to clean up.
RE: Making a file in the working directory not be managed by Subversion any more
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth Nico Kadel-Garcia <ma...@comcast.net>:
>> Even with the command-line client, you should be able to 'svn add .'
>> or 'svn add *' to add everything (equivalent to an import) and then
>> 'svn revert' those files that you *don't* want added. Easy, and you
>> get to verify that you've selected the right set of files before
>> finally committing.
>
> Be careful of "svn add *" forgetting to add files starting with "."..
> I've been bitten by that one: "svn add ." is safer.
The other gotcha is that 'svn add *' on a UNIXlike client will result in
the ignores getting ignored (ie. files that should have been ignored get
added regardless) in the current directory, while being properly ignored
for all subdirectories. Which makes sense if you remember how shell
expansion works, but is really weird the first time you see it :)
That's why I suggested the 'svn add .' first.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Making a file in the working directory not be managed by Subversion any more
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Gavin Lambert wrote:
> Quoth johann.petrak@gmail.com <ma...@gmail.com>:
>> I think an "unversion" command should be a standard part of
>> subversion: it can easily
>> happen that one puts unwanted files or even directories in the
>> repository by accident
>> when a big project is initially added.
>> It would probably be best to have a command that by default does what
>> the workaround
>> of copy/svn delete/copyback does, with a --force option that in
>> addition removes the complete history of the file from the repository
>> (this would be good to have if by accident very large files or
>> directories got added).
>
> It's a bit late once it's already in the repository, but to avoid
> these sorts of things I simply never use 'svn import' -- instead I
> use 'svn mkdir' to create an empty folder, then checkout that folder
> into my existing source tree. (SVN won't barf as long as the folder
> in the repo is empty, or at least that there aren't any clashing
> files.) Then I can specifically 'svn add' whatever files I need,
> which (since I usually use TSVN) is as simple as clicking a checkbox
> at commit time.
Me, too. The confusing and sometimes difficult to predict appending of
directory names by the svn import operation have created some big messes
that have been awkward to clean up in my work.
> Even with the command-line client, you should be able to 'svn add .'
> or 'svn add *' to add everything (equivalent to an import) and then
> 'svn revert' those files that you *don't* want added. Easy, and you
> get to verify that you've selected the right set of files before
> finally committing.
Be careful of "svn add *" forgetting to add files starting with ".".. I've
been bitten by that one: "svn add ." is safer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Making a file in the working directory not be managed by Subversion any more
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth johann.petrak@gmail.com <ma...@gmail.com>:
> I think an "unversion" command should be a standard part of
> subversion: it can easily
> happen that one puts unwanted files or even directories in the
> repository by accident
> when a big project is initially added.
> It would probably be best to have a command that by default does what
> the workaround
> of copy/svn delete/copyback does, with a --force option that in
> addition removes the complete history of the file from the repository
> (this would be good to have if by accident very large files or
> directories got added).
It's a bit late once it's already in the repository, but to avoid these
sorts of things I simply never use 'svn import' -- instead I use 'svn
mkdir' to create an empty folder, then checkout that folder into my
existing source tree. (SVN won't barf as long as the folder in the repo
is empty, or at least that there aren't any clashing files.) Then I can
specifically 'svn add' whatever files I need, which (since I usually use
TSVN) is as simple as clicking a checkbox at commit time.
Even with the command-line client, you should be able to 'svn add .' or
'svn add *' to add everything (equivalent to an import) and then 'svn
revert' those files that you *don't* want added. Easy, and you get to
verify that you've selected the right set of files before finally
committing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Making a file in the working directory not be managed by Subversion any more
Posted by jo...@gmail.com.
I think an "unversion" command should be a standard part of subversion: it
can easily
happen that one puts unwanted files or even directories in the repository by
accident
when a big project is initially added.
It would probably be best to have a command that by default does what the
workaround
of copy/svn delete/copyback does, with a --force option that in addition
removes the complete
history of the file from the repository (this would be good to have if by
accident very large
files or directories got added).
On 3/17/06, Donald H Locker <do...@ptmelec.com> wrote:
>
> [apologies to Steve; I first sent this only to him, not the list.]
>
> I tried this, but when I did an svn update, the file was deleted in my
> working directory. (I think this is reasonable behaviour, but it wasn't
> what I really wanted.)
>
> Suggestions?
> (Right now I'm working on a dump/dumpfilter/load script to "unversion"
> all the files that I added at the "beginning of time" that are not
> really source files.)
>
> Donald.
> (is top-posting deprecated on this list?)
>
> Steve Williams wrote:
> > johann.petrak@gmail.com wrote:
> >
> >> What is the best way to make a file that has been managed by
> >> Subversion not be managed any more?
> >> For instance, if a file got accidently added to the repository, how to
> >> remove it from there without removing
> >> it from the working directory? Is there a way to "officially" drop it?
> >> (I believe it is impossible to remove all previous versions without
> >> re-building the repository, but what
> >> about simply removing it from now on?)
> >
> >
> >
> > copy file elsewhere
> > svn rm file
> > svn commit file
> > copy file back from elsewhere
> >
>
> --
> Donald H Locker
> PTM Electronics, Inc
> 734 426 9010
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Making a file in the working directory not be managed by Subversion
any more
Posted by Donald H Locker <do...@ptmelec.com>.
[apologies to Steve; I first sent this only to him, not the list.]
I tried this, but when I did an svn update, the file was deleted in my
working directory. (I think this is reasonable behaviour, but it wasn't
what I really wanted.)
Suggestions?
(Right now I'm working on a dump/dumpfilter/load script to "unversion"
all the files that I added at the "beginning of time" that are not
really source files.)
Donald.
(is top-posting deprecated on this list?)
Steve Williams wrote:
> johann.petrak@gmail.com wrote:
>
>> What is the best way to make a file that has been managed by
>> Subversion not be managed any more?
>> For instance, if a file got accidently added to the repository, how to
>> remove it from there without removing
>> it from the working directory? Is there a way to "officially" drop it?
>> (I believe it is impossible to remove all previous versions without
>> re-building the repository, but what
>> about simply removing it from now on?)
>
>
>
> copy file elsewhere
> svn rm file
> svn commit file
> copy file back from elsewhere
>
--
Donald H Locker
PTM Electronics, Inc
734 426 9010
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Making a file in the working directory not be managed by Subversion any more
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: "Steve Williams" <st...@kromestudios.com>
To: <us...@subversion.tigris.org>
Sent: Wednesday, March 15, 2006 6:24 PM
Subject: Re: Making a file in the working directory not be managed by
Subversion any more
> johann.petrak@gmail.com wrote:
>
>> What is the best way to make a file that has been managed by Subversion
>> not be managed any more?
>> For instance, if a file got accidently added to the repository, how to
>> remove it from there without removing
>> it from the working directory? Is there a way to "officially" drop it?
>> (I believe it is impossible to remove all previous versions without
>> re-building the repository, but what
>> about simply removing it from now on?)
>
>
> copy file elsewhere
> svn rm file
> svn commit file
> copy file back from elsewhere
And you might want to creat an "ignore" property, so it doesn't get added
back to the repository in the future.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Making a file in the working directory not be managed by Subversion
any more
Posted by Steve Williams <st...@kromestudios.com>.
johann.petrak@gmail.com wrote:
> What is the best way to make a file that has been managed by
> Subversion not be managed any more?
> For instance, if a file got accidently added to the repository, how to
> remove it from there without removing
> it from the working directory? Is there a way to "officially" drop it?
> (I believe it is impossible to remove all previous versions without
> re-building the repository, but what
> about simply removing it from now on?)
copy file elsewhere
svn rm file
svn commit file
copy file back from elsewhere
--
Sly
This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org