Re: Two feature requests - Remove from repo without delete from WC, and SVN import with filters

> pete@molehole.org wrote (originally to the TortoiseSVN list):
> >Use case:
> >I've just been handed a codebase to put into version control, as part of a
> >demonstration of Subversion source control at this new place that I work
> >at. So, I've created a repository and simply done an SVN Import (with TSVN)
> >on the top level of the tree. This imports all of the generated files and
> >so on.
>
> Importing generated files is a mistake. You shouldn't regard this as the
> normal way to proceed. You should attempt to get a nice clean tree in the
> first place, and there are several things you can do towards that:

I know it's a mistake, but in my case, where the codebase is one I haven't seen before, I judged it safer to import the lot and then remove what I find I _don't_ need, as opposed to cleaning the tree outside of the safety net of version control and then finding I'd broken it.

From the rest of your reply, it appears that I shall have what I want when Subversion implements the repository-defined autoprops, because then I can simply define what to ignore on import ahead of time, have that propagate to the client with which I'm doing the import, and then perform the import on my uncleaned tree. Right?

> * Set the "global-ignores" configuration option to filter out as many of the
> generated files as possible so they don't get imported in the first place.
>
> * Clean up the source tree before importing it, with a "make clean" or
> equivalent command and/or manual inspection. (OK, you said that you don't
> feel able to do that manually, but if you have an automatic method, use it.)
>
> * Start with an empty directory and use "add" instead of "import", so that
> you get the opportunity to tweak the result to your heart's content before
> committing it. That's what I do.
> <http://subversion.tigris.org/faq.html#in-place-import>
>
>
> Having said that, I acknowledge that sometimes one will accidentally commit
> generated files, and then need to remove them from version control. Your
> concern was to leave them in the working copy.
>
> 1. Why do you need to leave them on disk? It's not a big deal if a
> generated file is deleted: just re-build it. It only happens occasionally,
> so it's not a big overall cost even if the re-build takes a while.

The issue I've come across is not just auto-generated files. Sometimes, for example, there'll be a website, with a directory full of images that don't strictly speaking, need to be version controlled. Thumbnails, for example. Or a temp directory. Here, one wants the fact that there's a directory, but not the images inside it. It's happened in the past that I've added all the images to the repo where I didn't want to, and subsequently wanted to un-version-control them without deleting them from disk. The workaround is to export someplace, svn delete, set svn:ignore for that directory, and copy in the images. But then there's the problem that if one sets svn:ignore, recursively, from a higher point in the tree, the image directory's svn:ignore gets nuked and if one's not careful, the images will get put in, next commit, again.

> 2. You didn't say whether you were more interested in your own WC or other
> people's WCs. In your own WC, you can work around the problem but only in a
> clumsy way by copying the files and restoring them afterwards; is that your
> concern? In another person's WC, the problem only arises if the other
> person updated their WC between the time you commit the generated files and
> the time you remove them; but if they did that, they would have discovered
> the clash at that point and known that they have to sort something out.

I'm mostly interested in my own WC.

> >It would be lovely if I could simply mark items to be removed from source
> >control, as part of this "cleaning the imported tree" procedure, so I can
> >do it all with fewer operations (mark as removed (and optionally, ignore in
> >future), commit; instead of many: SVN delete thing, commit, build;
> >iterations).
>
> I don't understand that.

Here I'm talking more about TSVN's interface for importing rather than SVN's underlying facility for importing. I want to be able to see a list of files, and then tick/untick tickboxes to determine which are imported. I'd like to be able to pre-filter this list by defining filters up-front. I'd like it to be able to intelligently figure out what my svn:ignore property might be to satisfy what I eventually decide to include/exclude, and give me the option of setting it, after review.

> >[Second, separate feature request, really] What would be rather useful,
> >too, is an extension to SVN Import that takes an include and/or exclude set
> >of filters (like what one might put in svn:ignore) to at least eliminate
> >the stuff I _know_ needn't go in. [That way, one doesn't _have_ to start
> >with a clean tree]
>
> That's the existing "global-ignores" configuration option.

Yes. But I hadn't remembered to set it appropriately.

So, basically, I can eliminate needing to do what I want (mostly) if I set up the global-ignores ahead of time, and I shall be even more happy when I can do that on a per-repo basis?

Cheers
Pete

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 23 14:32:13 2005