> 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.
Received on 2012-10-30 14:56:07 CET