0

I got a versioned sub-directory filled up with many kinds of files and directories, *.c, *.h, *.a, *.so ..., etc. Besides, this stuff is partially modified every time once project is built, and very BIG such that when I commit from parent directory, this sub-directory slows down the progress very much.

The reason for svn being slow is obvious because svn need to parse into this sub-directory and list all of them in the commit dialog.

I need some way making svn ignore this sub-directory so that commit progress can speed up, and this way is limited only to local part, not server part (although I have never had to commit it, and might neither in the future, others do.)

Here is what I have done and went failed:

  • In commit dialog: right-click -> move to changelist -> ignore-on-commit.

    This method offers grouping feature, letting user to identify stuff more quickly, but no help on ignoring file/directory.

  • Right-click sub-directory -> TortoiseSVN -> Delete and add to ignore list.

    This method will delete sub-directory and this is not what I want.

  • Runtime Configuration Area - global-ignores option.

    Global-ignores subjects to extensions, and sub-directory contains *.c files as well. If I added *.c to global-ignores list, I will not able to commit *.c files in other directories!

EDIT: svn version is 1.6.17

Community
  • 1
  • 1
Andy Lin
  • 397
  • 1
  • 2
  • 21
  • Do you mean that you make a large number of local modifications that you don't want to commit to the repository? That's probably an unusual scenario, perhaps it helps if you provide some context and explain why that happens in the first place. – Álvaro González Jan 19 '20 at 12:36
  • Yes, and those local modifications are output results from building project – Andy Lin Jan 19 '20 at 12:38
  • So your organisation has decided to commit generated binaries to the repository but those binaries do not correspond to the actual source code? That's the part I don't really understand. Same with a build process that generates *.c and *.h files. Is it possible that you're using the same output folder for current code snapshots **and** stable releases? (BTW, svn 1.6.17 is almost 9 years ago, though I guess that shouldn't change anything.) – Álvaro González Jan 19 '20 at 12:43
  • Your interpretation is quite good and you're understanding correctly. Those versioned-and-generated binaries do not correspond to the actual source code, and I have no idea why author put it on repository in the first place. – Andy Lin Jan 19 '20 at 12:50
  • Does this answer your question? [Subversion: prevent local modifications to one file from being committed?](https://stackoverflow.com/questions/862950/subversion-prevent-local-modifications-to-one-file-from-being-committed) – Andy Lin Jan 19 '20 at 14:06

1 Answers1

1

Storing generated binaries in version control is normally discouraged, even when done right. My suggestion would be to completely remove every generated folder output from the repository and them add it to the parent folder's svn:ignore property so it's a fully local directory. Then, find a completely different mechanism to distribute binary releases; if it needs to be done within subversions, it'd suggest a new hierarchy in the repository, e.g. /branches/releases.

If fixing broken procedures is prohibited or discouraged (in my experience, "we've always done things this way" is law in many organisations), you can try doing a sparse checkout that doesn't include those folders or (if that doesn't work) configure your local build to generate its output elsewhere; at most, that'd mean dealing with a single file in the ignore-on-commit changelist.

Álvaro González
  • 142,137
  • 41
  • 261
  • 360
  • I also found that "Versioned files and folders can never be ignored - that's a feature of Subversion." from svn book – Andy Lin Jan 19 '20 at 14:02