[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Ignoring deleted files in working directory

From: Michael Eager <eager_at_eagercon.com>
Date: 2006-05-19 20:15:52 CEST

Gale, David wrote:
> Michael Eager wrote:
>>Duncan Murdoch wrote:
>>>On 5/19/2006 1:20 PM, Michael Eager wrote:
>>>>I've just installed Subversion and I'm new using it.
>>>>I want to use Subversion a little bit differently from
>>>>the usual source code management application and I'd like a little
>>>>I want to create a document archive in Subversion.
>>>>The archive will contain both current and historical
>>>>documents. I want the working directory to contain
>>>>only a subset of the files in the archive. I don't
>>>>want Subversion to complain about the files which are
>>>>missing from the working directory.
>>>>Subversion (as far as I can tell) only allows me to
>>>>checkout a full directory. Is there any way to check
>>>>out specific files from an archive?
>>>>Another alternative is to check out an entire directory
>>>>and then delete the unwanted files from the working
>>>>directory. Is there any way to tell Subversion to not
>>>>complain about missing files, for example, in a "svn
>>>>status" command? (I've thought about adding a command line option
>>>>to do just this.)
>>>>I've also thought about tagging old files with a
>>>>property like "svn:archive". Is there any way to
>>>>have Subversion only checkout certain files, such as
>>>>ones which do not have this property.
>>>>One idea which I considered and which does not work
>>>>is to import the historical documents into the archive
>>>>and then delete them. They are in the archive and
>>>>can be recovered, but this makes them invisible when
>>>>looking at the head of the revision tree, for example, when using
>>>>Any ideas or suggestions?
>>>I'd create two directories, "current" and "deleted". Check out
>>>current, and when you don't want a document there any more, mv it to
>>>You may want multiple subdirectories in deleted, if you want to
>>>re-use the same names for unrelated files, e.g. deleted/2005,
>>>deleted/2006, etc.
>>Yes, I thought about this, but it really doesn't address the problem.
>>The historical documents are not "deleted", they are just inactive.
>>When I need to update one of the historical documents, I want to be
>>able to check it out of the archive and work on it in the correct
>>in the document tree. I don't want to have to check it out of a
>>separate directory tree and move it to the real directory location.
>>I want a single archive, not two.
>>Thanks for the suggestion.
> In that caase, it doesn't sound like subversion will give you what
> you're looking for. Subversion requires you to check out an entire
> directory, and if you delete a checked-out file, it'll reappear the next
> time you do an update. If you want to use subversion, Duncan's solution
> is probably the closest option you'll find; if that's not satisfactory,
> I think you're going to have to do some poking around to find a
> different version control system that allows for single-file checkouts
> (I don't remember whether CVS allows this or not).

I don't anticipate doing updates from the repository. This isn't source
code management.

Duncan's suggestion to create two different trees and manage them manually
doesn't do what I want: maintain one archive where all documents reside,
while only certain documents are present in the working directory.

Managing two archives, one for current and one for historical, is
error prone. Changes in the current directory, such as creating a
new sub-directory or renaming files, would need to be done twice.

As I said, possibly adding an option to SVN to simply not complain
about deleted files might do what I want.

Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 19 20:17:20 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.