I see what you're saying about svn:externals. However, from my reading, and
my testing observations, you cannot use svn:externals to do branches and
tags, because the copies that are in the branch or tag are just a copy of
the svn:external properties identified in the original folder.
So, if you "check-out" the tag you just made from the svn:externals dir, and
make a change to the files in the tag, then those changes are reflected back
in the baseline or trunk code.
That is definitely not a desired "feature".
Am I misunderstanding what you're doing?
On 12/6/05, Scott Palmer <email@example.com> wrote:
> On 6-Dec-05, at 2:58 PM, Marc Sherman wrote:
> > Mark Phippard wrote:
> >> Matthew Wheaton <firstname.lastname@example.org> wrote on 12/06/2005 02:35:55
> >> PM:
> >>> Totally understood. I know that it would not be an atomic commit,
> >>> but
> >> the
> >>> Subclipse plugin (or patch to it), could do what I described on
> >>> each URL
> >>> (selected project, or folder), could it not, instead of repeating
> >>> the
> >>> operation for each folder ?
> >> Probably. I am not sure it is something I would want to do though.
> > I agree. It goes against best practises for subversion. The OP
> > really
> > should restructure their repository to have the project dirs at root,
> > with separate trunk/tags/branches for each project, if they're really
> > independent.
> The OP mentioned many independent projects that all make use of a
> shared project. I see that pattern a lot,and I don't think it is a
> bad practice in general.
> I usually use svn:externals to build a workspace when I have that
> situation. So I will have a ProjectXWorkspace folder in subversion
> that pulls in 'ProjectX' and 'CommonCode' under a single parent
> directory, the workspace folder in subversion may not have any
> childred at all, just the svn:externals property, though sometimes it
> has a build script or README. I only wish that svn:internals or
> some other equivalent for server-side symbolic links would get
> implemented so this would work a bit better. (no I don't have time
> to submit a patch :) )
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Dec 7 08:35:15 2005