> 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
A couple of thoughts.
Each developer for their specific platform could have a global ignores files that ignores the files that are specific to their platform/tool. You can generate a global ignore file since it is just a text file and place it in the correct location.
Configure your build system and tools to place all build artifacts into an ignored work folder and copy files that are versioned into their correct locations.
If the build is doing the "add" then it could create the svn:ignore property, do the "add" and then remove the property.
Just some other possiblitites.
BOb
Received on 2012-10-29 20:51:07 CET