[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Enhancement suggestion

From: Jeffrey Creem <jeff_at_thecreems.com>
Date: 2005-03-03 03:46:24 CET

Brad O'Hearne wrote:

> I don't know if this is the proper place to post an enhancement
> request, but I was thinking that an interesting feature would be the
> ability to have files flagged to be handled with context-sensitive
> versioning. In other words, 99% of the content of my projects
> contains code that's global, for any user that uses the project.
> However, there are configuration files, either for users or for
> deployment situations that I would like to be slightly different based
> on the context they are used in. It would be really cool to be able to
> have these configuration files overloaded within a revision number, by
> some uniquely identifying context. So for example, if a project is at
> revision 10, and within my codebase I have a brad.conf file, which is
> slightly different depending on whether I am building for development
> or production environments, I could do something like the following:
> svn checkout -r 10 -context "dev"
> OR
> svn checkout -r 10 -context "prod"

Funny..This is somewhat like the request I just posed a few days ago
(though really a small subset of it) comparing the capabilities of SVN
to Rational (Now IBM) Apex (Now Ada developer).

Apex has a some concepts that allow for this and I use them all the time
in my projects. Based on some suggestions here and elsewhere I've looked
into several approaches (like using exterals, or properties with scripts
and a few other things). Basically none of the approaches seem to come
close to what I can do in Apex in this area (of course there are a lot
of things I can do in SVN that are better so to some extent it is just a
matter of getting used to using tools the way they are meant to be used).

Having said that, it really does feel like a cool missing feature that
probably requires more than just a single example to fully explain
(especially to place it in a context that makes sense for the way SVN
manages things v.s. the way apex does it).

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 3 03:48:45 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.