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

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-10-23 12:31:31 CEST

pete@molehole.org wrote (originally to the TortoiseSVN list):
> I realise this has been debated to some minor (heh) extent before, but it would
> be really useful to be able to remove something from version control, without
> deleting it from disk. Perhaps also having the option to add it [or a range of
> files based on the selected files' filenames/extensions] to the ignore list
> [TSVN keeps a client-side ignore list] in the same step.

This has been discussed on this list, but the idea is still too vague to decide
whether it is even conceptually possible to make it behave sensibly in all
circumstances. Feel free to make a precise proposal of what it would do; after
all, this certainly isn't going to happen until someone does.

> 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:

* 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.

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.

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.

> 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.

> [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.

- Julian

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

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

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