Feature request 'svn ignore'

[Daniel Hirsmuller-Counts <li...@gmail.com>]

I hope this is the right place for a feature request. I'm working on a
ruby on rails project, using subversion as our version control system.
Each developer checks out a working copy of the project and sets up
their own lighttpd and mysql servers on  their development machine.
Several config files are in the repository and its very useful for the
developers to get copies of these files when they check out their
working copy. However, it would be nice for developers to be able to
customize these config files to work with their system. If the
developers do this, the modified config files get committed whenever
the developer commits their next revision. Then when another developer
goes to update their working copy they get the new (customized) config
files and have to re-configure their config files. Enough of this
anecdote it would be nice to have a svn command to tell subversion to
"don't look at my changes". I purpose something similar to the
following command.

svn ignore <filename>

I know that svn propedit svn:ignore can do something similar for new
files that haven't been committed to the repository, but I'm looking
for a functionality that will work with files already in the
repository.  As I mentioned above I am a developer and I would be
willing to volunteer my time to work on adding this feature.



-- 
Hardware (Noun.) - The part of a computer system you can kick.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Feature request 'svn ignore'

["F.J. Weiland" <fj...@effjay.com>]

<snipped>
> working copy. However, it would be nice for developers to be able to
> customize these config files to work with their system. If the
> developers do this, the modified config files get committed whenever
> the developer commits their next revision. Then when another developer
> goes to update their working copy they get the new (customized) config
> files and have to re-configure their config files.
<snipped>

While not directly dealing with your "ignore" request, we have a similar
situation wr2 multiple developers, environments & customized config files
for building, but we've got a different way of handling the problem that
avoids the conflict you've identified, yet allows us to preserve all the
customizations for each environment.

This has worked for the projects where we've used Ant as the build tool.

Briefly, our build scripts for a given project don't change across
environments (e.g. machines belonging to bob, joe, ted, or for qa, dev, or
prod). We've externalized all environment-specific settings to separate
data files, all of which are uniquely keyed by name to their environment
(e.g. bob.settings, dev.settings, etc.). Each system where we do a build
has some environment variables set that identify it so that the build
script picks up the identifying value as it starts up and uses it to pick
which settings to continue execution with.

e.g.
start a build on bob's machine.
build script picks up identifier 'bob' from the local OS environment.
build script slurps in the 'bob.settings' file and uses bob's settings to
build with.

Advantages:
- build scripts don't have to change for a project across environments.
- any truly special behavior, like some special logic for a production
build, can be built into the script and executed or not because the script
"knows" what it's building against and can branch its logic accordingly.
- everybody can preserve their custom settings in source control, nobody's
settings have to be 'ignored' (and subject to loss).

Obviously, you have to work out a system of unique identifiers for each
environment, but there's lots of ways to do that. We're not a very big
shop, so names, initials, and abbreviations works for us, but you could
use hostnames, for instance.

When I'm checking out or looking at status of the project, it's irrelevant
but harmless if bob's settings are up to date on my machine or not, it's
only important to me that mine are up to date, but both bob's and mine are
in source control as part of the project. If I lose my machine for any
reason, that's one set of configurations I don't have to try to remember,
at least. In our repository, each project has a couple of folders that
contain all these settings files - just used to build with - so they don't
clutter up the rest of the project tree.

for the record, i can take no credit for any part of this system -- some
other guys here figured it out and set it up. it's simple and has worked
well for us across a large number of projects for the last few years.

perhaps you might find a similar approach useful.

good luck.
regards,
-fj

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Feature request 'svn ignore'

[Max Bowsher <ma...@ukf.net>]

Max Bowsher wrote:
> Daniel Hirsmuller-Counts wrote:
>> I hope this is the right place for a feature request. I'm working on a
>> ruby on rails project, using subversion as our version control system.
>> Each developer checks out a working copy of the project and sets up
>> their own lighttpd and mysql servers on  their development machine.
>> Several config files are in the repository and its very useful for the
>> developers to get copies of these files when they check out their
>> working copy. However, it would be nice for developers to be able to
>> customize these config files to work with their system. If the
>> developers do this, the modified config files get committed whenever
>> the developer commits their next revision. Then when another developer
>> goes to update their working copy they get the new (customized) config
>> files and have to re-configure their config files. Enough of this
>> anecdote it would be nice to have a svn command to tell subversion to
>> "don't look at my changes". I purpose something similar to the
>> following command.
>>
>> svn ignore <filename>
>>
>> I know that svn propedit svn:ignore can do something similar for new
>> files that haven't been committed to the repository, but I'm looking
>> for a functionality that will work with files already in the
>> repository.  As I mentioned above I am a developer and I would be
>> willing to volunteer my time to work on adding this feature.
> 
> http://subversion.tigris.org/faq.html#ignore-commit

Umm, oops.
I managed to set an utterly bogus Reply-To header on my last message.
Please don't reply to it, reply to this one instead.

Max.

Re: Feature request 'svn ignore'

[Max Bowsher <ma...@ukf.net>]

Daniel Hirsmuller-Counts wrote:
> I hope this is the right place for a feature request. I'm working on a
> ruby on rails project, using subversion as our version control system.
> Each developer checks out a working copy of the project and sets up
> their own lighttpd and mysql servers on  their development machine.
> Several config files are in the repository and its very useful for the
> developers to get copies of these files when they check out their
> working copy. However, it would be nice for developers to be able to
> customize these config files to work with their system. If the
> developers do this, the modified config files get committed whenever
> the developer commits their next revision. Then when another developer
> goes to update their working copy they get the new (customized) config
> files and have to re-configure their config files. Enough of this
> anecdote it would be nice to have a svn command to tell subversion to
> "don't look at my changes". I purpose something similar to the
> following command.
> 
> svn ignore <filename>
> 
> I know that svn propedit svn:ignore can do something similar for new
> files that haven't been committed to the repository, but I'm looking
> for a functionality that will work with files already in the
> repository.  As I mentioned above I am a developer and I would be
> willing to volunteer my time to work on adding this feature.

http://subversion.tigris.org/faq.html#ignore-commit

Max.