Gale, David wrote:
> Michael Eager wrote:
>
>>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 advice.
>>>>>>
>>>>>>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
>>>>>>ViewVC.
>>>>>>
>>>>>>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 deleted.
>>>>>
>>>>>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
>>>>place 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.
>
>
> So, if you're only ever going to have the one working copy (or, at
> least, only one working copy that's going to commit changes), you
> *could* checkout the entire directory and delete all the "inactive"
> files (through rm, not svn rm), as you'd suggested. Then, if you need
> to update an inactive file, just do an svn update on it to make it
> reappear. Getting svn status to not complain about missing files would
> be fairly easy to do by wrapping it, so that instead of calling it
> directly, you really do something along the lines of:
>
> svn status | grep -v '^!'
Yep, I might do that, before I decide to muck with the SVN code.
> Feels odd to me, but that's because I'm used to thinking along the lines
> of concurrent development, etc. If it works for you, great.
Yes, it is a different application. It's possible that there
might be modifications being done by different people at the
same time, but it's not likely that the same document would be
changed, so there is little issue with merging. I'd have to look
at how to handle updates, perhaps only updating files which were
present in the working directory, plus new files added to the
repository.
--
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 22:34:03 2006