Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
I don't think I did fully understand the interaction between your build system and your devs, as normally build systems like Jenkins, Hudson etc. run on a separate server fully automated and per default just don't commit anything, therefore it's very unimportant if the working copy they are working on is flagged as changed in any way or not. So your build system is used on the devs machines and works on the same working copy as your devs work on that you get a problem with svn status? Maybe I called our system the wrong name. It is a homemade system, and here are some of the things that it does: 1) Each project is specified by a custom configuration file, which lists the source files to be compiled using different tools and sets up project-specific options. These configuration files are versioned and may contain conditional options based on target platform and other global options. 2) A developer chooses from a list which projects he wishes to work on, and edits a configuration file to indicate the platform he wishes to compile to, build flags and several other options. These local options are specified by locally modifying a versioned template file. The modified file is marked as ignored, no problems here. 3) The system checks out or updates all relevant code from the repository, including the selected projects and, depending on the local options, other projects on which they depend, or that depend on them. This is done with svn sparse directories, no problems either. 4) The system automatically generates platform- and option-dependent files, such as makefiles on Linux and Visual Studio project and solution files on Windows. These are marked as ignored. 5) Before compilation, several tools produce some automatically-generated source code, such as bindings between two programming languages. These files can be different depending on the target platform and other options, and there can be quite a lot of them. They should also be marked as ignored, but there is no naming pattern or specific location for them, which makes it hard to use global ignore patterns. Since the automatically-generated files are often #included in other non-automatic source files, the developer is free to choose the location and naming which are best for him. The names and locations are specified in the project configuration files. 6) After compilation, the system copies some files around, such as exported library headers and DLL dependencies of the generated executables. 7) The system also automatically generates installation scripts and executables for the end-users. Number 5 above is probably the most problematic case. We _could_ try to impose a specific location and naming pattern for those files, but this could affect headers used by client developers as well, so we would rather avoid that if possible. Which subversion clients do you use? TortoiseSVN in Windows, just the command line in Unix.
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
Just to be clear: What you call your build system is used directly by the devs and something we can think of as some kind of assistant to get pre configured working copies, right? The devs start this assistant, choose whatever fits their need and afterwards it is checking out, setting up and compiling things etc. and during that process svn working copies are created with versioned files with local modifications which should be ignored in svn status and comparable operations. That is almost correct. You got the nature of the system right, but it does not create versioned files with local modifications. It creates several unversioned files, which should be ignored as well. These files do not follow any naming or directory layout convention, their names and locations are freely specified as part of each project's specification, which is kept in versioned per-project configuration files. The unversioned files are the main problem. If I understood correctly and you don't have any naming or directory layout convention to ignore the best chance in my opinion is your build system, as if it knows what it does automatically and should be ignored it should get capable of providing that information to svn. It could update the user wide configuration for ignore patterns of Subversion or specify paths to exclude for Tortoise etc. Yes, indeed, the system knows exactly what should be ignored given the current in-development projects and other configuration options. With CVS, it marked these files as ignored by locally editing the .cvsignore file inside each folder, which did not have any undesired effect. Now, with SVN, our first idea was to locally edit each folder's svn:ignore property. However, since svn:ignore is itself versioned, every folder is always inconveniently marked as locally modified (property change only) by SVN, because the list of ignored files is different depending on the chosen projects and configuration options. And now we're back at my first post, self-quoted below. I can't help but think that there should be an unversioned list of ignored file patterns (.svnignore local file or svn:localignore property or something like that) as well as the versioned svn:ignore property. (self-quote) The only solution I could think of (to be able to keep a somewhat stable svn:ignore property) would be to populate the svn:ignore property with every file that could ever be automatically generated by the build system when operating in each and every local configuration scenario. Even then, however, there is still some unnecessary hassle: - For the property to be automatically updated, the build system would have to simulate every possible configuration (lots of possibilities) to update the svn:ignore property, which is a lot more work that working only with the single, currently selected configuration. - The system could get the current svn:ignore property and only add new items to it based on the currently selected configuration, but this may result in unnecessarily bloated svn:ignore properties over time, since no-longer-generated files would never be removed from the list. - If the property is to be managed manually, then the developers must remember to always update the svn:ignore property themselves every time a new file is automatically generated or an old file ceases to be generated. This is error-prone and requires every developer to know about the internals of the build system. The second option above is the strongest solution in my opinion, but it is still more complex than a simple .svnignore file (or an extra unversioned ignore property), and yet results in a not-as-good behavior.
Re: SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
I'm not quite sure if you really understand the impact of svn:ignore. What behaviour are you expecting from the svn:ignore mechanism exactly, and how would the expected behaviour impact your workflow? We want the unversioned files to not show in svn status or in tortoiseSVN's Add command when invoked on directories which contain unversioned files. I'll talk to other devs to see if there are other expected behaviors. Based on past experience, I would guess that this is probably not as simple as you imagine it to be, unfortunately. You are talking about a major feature addition, not some small fix. Subversion has no concept of an unversioned property yet. Such a concept would need to be added first which would require some design and implementation effort. A lot of work would need to be done to make sure this new kind of property interacts well with all other features of the system (status, diff, commit, update, ...). That means writing a lot regression tests to start with. This might turn out to be about as simple as the file external feature turned out to be. A very simple idea on the surface but very hard to get working correctly in all use cases, and we ended up frantically fixing a lot of new bugs related to the feature over the course of several months. Alright, I got the picture. Don't worry, I'll look deeper into the matter and make a good effort to make things work nicely on our side before asking for such a feature. See below. We do exactly the same thing in Subversion itself, and we do have ignore patterns like *.c and so on within the bindings source directories. There doesn't seem to be any problem with this in our project. This command lists the patterns we use: svn propget -v -R svn:ignore https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings The problem is that the C files automatically generated for bindings are often mixed with standard versioned C files... However, after further inspection here, it seems to me that the binding files could indeed be put in a separate directory without requiring any code to be changed. My main concern is with the exported header files, but their names don't seem to vary much with the target platform and other compilation options in our system. Maybe I can tell Subversion to ignore the headers individually and also a special bindings directory containing the implementations. I'm going to investigate this further, maybe there is a way to adapt our system without requiring code changes after all. I'll report here soon.
SVN offers svn:ignore property, but I also need some kind of .svnignore local file (or an extra unversioned version of svn:ignore)
Hello all, I have searched for this issue in several places, but none of the feature requesters presented a scenario like mine, and the overall conclusion was that the svn:ignore property was sufficient. However, I stand by the opinion that a local .svnignore file is also necessary (or some kind of _unversioned_ svn:localignore property). So, I'd like to see some additional opinions on the matter. Details follow. I have a build system that allows me to compile C/C++ code from a single repository for a number of different platforms, including several flavors of 32- and 64-bit Windows, Linux and MAC. During setup and compilation, the system generates several local files, which are different depending on the selected target platform, the selected in-development projects, and some other local configurations. These files are unversioned and should be ignored by the versioning tool. Until some time ago, I used CVS as my versioning tool, and the .cvsignore file worked perfectly. The build system knows what files will be generated for the current configuration, so it just created the .cvsignore file and filled it with the names of those files. Now, I have migrated my repository to SVN, and I am having trouble with the fact that the svn:ignore property is versioned. Since the list of ignored files varies with the local configuration, it is usually different for each developer in my team, and the source-code folders are always marked by SVN as modified, which is kind of inconvenient. The only solution I could think of (to be able to keep a somewhat stable svn:ignore property) would be to populate the svn:ignore property with every file that could ever be automatically generated by the build system when operating in each and every local configuration scenario. Even then, however, there is still some unnecessary hassle: - For the property to be automatically updated, the build system would have to simulate every possible configuration (lots of possibilities) to update the svn:ignore property, which is a lot more work that working only with the single, currently selected configuration. - The system could get the current svn:ignore property and only add new items to it based on the currently selected configuration, but this may result in unnecessarily bloated svn:ignore properties over time, since no-longer-generated files would never be removed from the list. - If the property is to be managed manually, then the developers must remember to always update the svn:ignore property themselves every time a new file is automatically generated or an old file ceases to be generated. This is error-prone and requires every developer to know about the internals of the build system. The second option above is the strongest solution in my opinion, but it is still more complex than a simple .svnignore file (or an extra unversioned ignore property), and yet results in a not-as-good behavior. So, I would like to know if anyone has a better idea, and/or if anyone agrees that a local .svnignore file (or an extra unversioned svn:ignore property) has a good use after all. Thanks for the attention, Vitor
