certainly an open-source moment. ;-)
Stefan Küng wrote:
> Simon Large wrote:
>> On 27/07/07, Stefan Küng <firstname.lastname@example.org> wrote:
>>> fj wrote:
>>>> Julien -
>>>> Yep, I know exactly what you mean, and I agree this would be useful.
>>>> Config files are a very good example of this. At one place I worked we
>>>> had standardized build files (Ant) that we'd include with each new
>>>> project set-up. Anyone needing to set themselves up to run builds
>>>> made a
>>>> number of path modifications to their local working copies of those
>>>> files. Generally, we didn't check-in any of those modified files
>>>> potentially we'd have as many different variations of them as there
>>>> machines on which builds were set up to run.
>>> Please have a look at the TSVN build scripts (they're NAnt scripts, not
>>> Ant, but you'll get the point).
>>> We also have to use (sometimes) full paths, but we put those into
>>> separate files (*.tmpl), which each user has to make a copy, remove the
>>> .tmpl extension of the copy, then edit that file to suit the
>>> absolute paths.
>>> The main build script checks if those user defined files are present
>>> errors out if they're not.
>> This one keeps coming up periodically. Sometimes it's really not easy
>> to solve. I once worked with a compiler IDE that kept the project
>> source file list and config details in the same file as the workspace
>> info. Every time you open the IDE, the project file changes. It has to
>> be versioned, but it only needs to be committed when project
>> definitions change.
>> Another idea which has just occurred to me is that we could use the
>> changesets feature for this purpose. As well as the user-defined
>> changeset names we have at the moment, you could add another one with
>> a fixed name, like TSVN-ignored-changes. Files added to this set would
>> be automatically deselected on entry to the commit dialog, and they
>> could be shown greyed out maybe.
>> In terms of UI, the context menu would have
>> Move to changelist
>> My existing changes
>> Ignored changes
>> <new changelist>
>> The 'Ignored changes' item is always present in the menu, even if that
>> changelist has not been created yet. This menu entry is translatable
>> and maps to our fixed-name changeset.
> Now that's really a good idea on how to "solve" these problems,
> without disturbing other features or messing around with important
> Done in revision 10260.
> The changeset is named "commit-ignore". (which of course is open for
> discussion - it's just a define for now).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jul 30 02:39:48 2007