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

RE: Copying (branch/tag), dumping, and filtering repository contents

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-09-05 14:24:59 CEST

Alright, one more time, and then I give up. I though this would be a
relatively simple question, but apparently I was wrong.

> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> Sent: Friday, August 24, 2007 9:08 AM
> To: Bicking, David (HHoldings, IT); users@subversion.tigris.org
> Subject: RE: Copying (branch/tag), dumping, and filtering
> repository contents
>
> I'm reposting a question below, as nobody answered yet.
>
> > As most of you know from my prior questions (still hoping for some
> > more replies), I am dealing with repository load issues.
> > I lack understanding about how the revision histories
> work, and the
> > effect upon dump filters.
> >
> > What are the best practices in project structure management with
> > respect to dumps and filters? I read and understand
> everything about
> > the trunk, branches, and tags layout, but I am in the dark about
> > dumping, filtering and loading.
> >
> > Given the standard layout, if I were to dump the repository
> and filter
> > for a specific TAG, what would happen? Would I get a message about
> > revisions not being found because they're in TRUNK? If
> not, would I
> > get all the revisions right back to the initial ADD, which
> occurred in
> > trunk? If not, is this considered a problem?
> >
> > For example, as a DotNet shop, we have several projects that are
> > referenced together in "solutions". Several of those projects are
> > effectively "shared" in that they are common libraries, but are
> > maintained as source code references (rather than DLL
> references) to
> > permit ongoing development.
> > The application itself, "/Projects/AAA" has
> > 3 or 4 projects that aren't shared.
> >
> > Eventually, we decide to start a new branch of the core
> project, so we
> > create the branch of AAA (/Projects/AAA/Branches/R2"). We
> might not
> > decide to branch the Common ("/Projects/Common") projects.
> >
> > So:
> > /Projects/Common
> > Trunk
> > ------|---- Common1
> > |---- Common2 ...
> > Branches
> > Tags
> >
> > /Projects/AAA
> > Trunk
> > Branches
> > R2
> > |----View
> > |----Business
> > |----DAL
> > Tags
> >
> > The solution contains:
> > MySln.sln
> > Common1
> > Common2
> > View
> > Business
> > DAL
> >
> > Months go by, and we decide that we want to move R2 and associated
> > Common projects into a new repository. How would I do
> that? For that
> > matter, would we be able to maintain a Visual Studio solution that
> > referenced two different SVN sources as shown above?
> >
> >
> > --
> > David Bicking
> >
> >
> > **************************************************************
> > ***********
> > This communication, including attachments, is for the
> exclusive use of
> > addressee and may contain proprietary, confidential and/or
> privileged
> > information. If you are not the intended recipient, any
> use, copying,
> > disclosure, dissemination or distribution is strictly
> prohibited. If
> > you are not the intended recipient, please notify the sender
> > immediately by return e-mail, delete this communication and destroy
> > all copies.
> > **************************************************************
> > ***********
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >

*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 5 14:22:12 2007

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.