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

Re: Re: Subversion source folder mapping to local folders question (is it many to many)

From: Andy Levy <andy.levy_at_gmail.com>
Date: 2006-04-04 16:44:01 CEST

On 4/4/06, Weaver, Chris (Indust, PTL) <chris.weaver@penske.com> wrote:
> I looked at the externals and it doesn't do what I need.
> We have used VSS in the past and we separated the static and dynamic web content into two separate folders in VSS and then mapped those two folders to the same local folder. We also used the same idea with our Prod/Qa/Dev specific files. I am not sure how you can fit these into the Trunk/Branch/Tag paradigm. Have any suggestions?

I don't think this has anything to do with the "Trunk/Branch/Tag
paradigm" but rather the general project layout.

It sounds like you've separated, in VSS, 2 things that need to be
merged into one when making a release. This really is an unnecessary
step and can lead to quite a bit of confusion and difficulty, as
you're finding.

Why do your static and dynamic elements need to be separate in source
control in the first place, if they are merged in the final product?
The only reason I can see for doing so is if you have 2 separate and
distinct people/groups working on each of those segments. If that's
the case, I'd have a build script which exports the items needed for
the build and shuffles them around - but really, to make things
easier, it's better to just have your source tree mimic the build or
web server environment. That way developers can check out, build and
run the application on their local workstations (local unit testing).

Environment-specific files are a PITA regardless of your SCM software.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 4 16:46:09 2006

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.