Why are build artifacts not ignored by svn

[dneise]

I remember, that I once tried to add the build artifacts (*Cint.cc, *Cint.hm *Dep.d) created by the Mars build system to the svn:ignore property, but it was not regarded reasonable that time.

I wanted to inform you, that there is a trivial way to ignore these artifacts without actually touching our svn repository, and thereby not affecting others.

In Ubuntu you should find a file called ~/.subversion/config in your home.
In order to ignore those files scroll down to the [miscellany] section and
uncomment the 'global-ignores' line and simply append this to that line:

*Cint.cc *Cint.h *Dep.d

so in my case it looks like this

global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo __pycache__
     *.rej *~ #*# .#* .*.swp .DS_Store
     *Cint.cc *Cint.h *Dep.d

I still get shown all the binaries like (star, merpp, callisto, ...) that are build and wonder weather I should include them also into my global-ignores... not sure yet ...

I still would rather like to include this into the svn:ignore property so not everybody has to edit his .subversion/config, but I guess it is still considered a no go, right?

[tbretz]

The solution is much much simpler!

Never make an "svn add" on a whole directory, except you cleaned up your directory first and crosschecked.

No need for any ignore. NOTHING which wasn't checked before should be "added" (you will see those artifacts before you add!) nor be "submitted" (files not in the svn will not magically appear, so they are ignored anyways).

There is _no_ need to touch the svn configuration or the svn:ignore. The only thing you do is you create a hidden behaviour. So please don't touch the svn:ignore if you don't have a real reason to do so.

Check your own actions before you take action instead of creating magical configurations which only help your own laziness but may create headaches for other peoples the other day.

Of course you can still add them to suppress that they get listed when you do a "svn diff".. but what's the point? You can use grep as well.

[tbretz]

Oh... and you should never "svn add" a whole directory in which you have done actions already other than just creating/copying the files there. (So you make sure there will never be any build artefacts)

[dneise]

I was actually not refering to svn add but to svn status

I had the impression, that ignoring build artifacts is a common thing to do, just not in Mars.

To quote from the svn book chapter 3

In this example, you have made some property modifications to button.c, but in your working copy, you also have some unversioned files: the latest calculator program that you've compiled from your source code, a source file named data.c, and a set of debugging output logfiles.
Now, you know that your build system always results in the calculator program being generated. And you know that your test suite always leaves those debugging logfiles lying around. These facts are true for all working copies of this project, not just your own. And you know that you aren't interested in seeing those things every time you run svn status, and you are pretty sure that nobody else is interested in them either. So you use svn propedit svn:ignore calc to add some ignore patterns to the calc directory.

​http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html

[dneise]

Of course you can still add them to suppress that they get listed when you do a "svn diff".. but what's the point? You can use grep as well.

Have you installed 'ls' on your system? What's the point? There are other ways to get a file listing without that silly 'ls' thing :-)
​http://www.theunixschool.com/2010/09/5-different-ways-to-do-file-listing.html

No, I'm kidding.

The point is: As much as it is conventional to use 'ls' to do a file listing, it is conventional to use 'svn status' so see what has changed without having your screen cluttered up with stuff, that is not interesting to the vanilla developer.

Of course in FACT/Mars one can do:

svn status | grep -v '?'

in order to filter away the build artifacts, but it also filters away all new files, the developer might has created on purpose ...
Or one can do:

svn diff | grep Index

as you wrote in https://trac.fact-project.org/wiki/SvnRules

And, yes, one can create aliases to those commands, in order to save some key strokes. *But* and that is my point, it is unconventional. And the point of conventions is to greatly reduce the amount of documentation needed. (The impression, that documentation is missing in many places in FACT, might either be true, or just be a hint, that we should try to stick to conventions a little more here and there)

We could have agreed, to use red cables in FACT for signaling and black cables for supply voltage and colored cables for GND. All we would've needed to do, is documenting our decision and go for it. But we didn't because our electronics was made by engineers, I guess. And engineers know about the value of conventions. Actually the process of software creation is also quite often referred to as software engineering.... I think there is some truth in this terminlogy.

Now of course one can argue about what is a proper source for conventions regarding the use of SVN. I believe, the red book truly can be considered as the source of information about SVN setup and usage. Would you agree here, or would you rather suggest another book?

Also I would like to understand a little more, what is the actual problem you have ever encountered when ignoring build artifacts in SVN?
You say further up there:

Check your own actions before you take action instead of creating magical configurations which only help your own laziness but may create headaches for other peoples the other day.

I don't quite see the situation, in which a developer becomes confused by build artifacts not being shown by SVN. But I guess there must be a strong use case, I am simply missing. Maybe if you elaborate a bit on your personal std working style, I could understand it better.

(Btw, please don't call me lazy in the public, I'd rather keep the discussion on a professional than personal level. I think, everybody can expect a bare minimum level of respect from his colleagues.)

---

As a closing remark I would like to add. I am not writing this, because I can't live with the current situation (I created those aliases already, and I am used to them now).
I wrote this ticket, because I was in the situation to explain people, how to use svn status in FACT/Mars, because they were confused by the large amount of output.

They complained about it, and I thought I should try to find a solution that does not involve touching the svn:ingore property of the FACT/Mars repository, because I already knew about your dislike of this.