Brad
At 10:08 am 3/03/2005, 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.
I'm looking for something similar. I haven't had any experience with
subversion yet (because I haven't had the time to set it up - but my
intentions are good!) however I had assumed I would have to deal externally
with extracting different sources for particular builds.
80% of my source is common to a number of separate applications used in
different markets.
I want an unattended machine to check out the appropriate sources on a
regular schedule and build the different applications for automatic
testing. Again, I haven't yet thought deeply about the scripting necessary
to do this but I do have good intentions.
If subversion can make life easier for me I'm keen to support Brad's
suggestion.
Mike
>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"
>
>and I would get the exact revision, with variances in brad.conf for dev
>and prod. The thing about files like brad.conf and similar config files
>this is that neither one (the dev or prod version) is really a progressive
>revision of the other, so to just commit changes is going to be
>perpetually redundant, and required whenever a deploy is done.
>Additionally, it doesn't fit the use case for a branch very well. It also
>mushrooms admin if you store multiple copies of these things -- this is
>merely a small example, but it would require changing associated builds to
>pull files from different places and other types of overhead just to work
>with multiple copies of the file within a revision that reside in
>different places, the location denoting the context.
>
>So having the ability to have multiple contexts for a file within the same
>revision seems useful. Thoughts?
>
>Brad
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 3 00:30:54 2005