On 5/14/07, Olivier Dagenais <olivier.dagenais@formark.com> wrote:
>
> > The problem is that we have many different sites and some parts of the
> > site run common "software" such as a members area that is standard for
> > each
> > site except for layout changes and so on. So what I need to do is
> checkout
> > the sites code, that is no problem. But then the structure of that site
> > would have a web directory and in that directory there would be another
> > called members. Now into that directory I would need to checkout another
> > repository, that contains our members software. Now I have just been
> > testing
> > on my local machine using TortoiseSVN and it seems I can not checkout
> > another project into that directory.
>
> I see what you're trying to do, but I would do it differently: I would
> commit a copy of the "standard" bits to each site's repository, with a
> note
> in the commit comment (and/or a subversion folder property?) as to which
> revision of the standard bits have been updated. That makes the sites'
> make-up less of a moving target and more predictable because you need only
> ask for code from one repository when it's time to test a site. It also
> means fixes done in that "branch" will need to be propagated into the
> authoritative repository on occasion, but it does make it such that those
> hypothetical "fixes" (ok, "hacks") for one site won't risk jeopardizing
> other sites.
>
> That's the approach we use when we have projects use a common class
> library.
> Since your "standard" software may consist of many more files than a class
> library and its associated documentation, you may choose to commit a ZIP
> file that contains all files and have your build script unzip it into the
> appropriate folder when compiling. Your "pull" updates would be easier
> this
> way, but your repository might grow in size faster as a result and private
> changes will be incredibly difficult.
>
> > Will I have to check them outside the site area and then copy them
> > manually?
>
> If anything, you'll end up writing a batch file that performs a checkout
> of
> one repository and an export of another.
>
> > And is there a way to get rid of the .svn folders in a working copy so
> > that
> > they do not end up on a site?
>
> That would be an "export", which asks Subversion for "an unversioned copy
> of
> a tree"; in other words just the files in the repository and none of the
> "control folders" (.svn).
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Olivier Dagenais
> Software Engineering / Génie logiciel
> Formark - Combine the Best of SharePoint(r) and Livelink(r)
> Phone: 613-599-5173 ext 238
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Make sure you don't miss anything: subscribe to the Formark Newsletter:
> http://www.formark.com/support/register/index.asp
>
>
I see what you are trying to suggest. I had never thought of it that way.
The problem I see with that method is that the other package that gets
inserted into the site gets changed as much if not more then the site itself
and when it was updated I would have to commit it to the 15 repositories
that use that software.
An export had totally slipped my mind (I am new to subversion). For a
website then, would it not be better to do only an export of both
repositories, since that way the website will not contain any svn files at
all?
Thanks for the suggestions,
Brent
Received on Tue May 15 02:02:19 2007