On 29-Jun-2006, Ryan Schmidt <subversion-2006q2@ryandesign.com> wrote:
>
> On Jun 29, 2006, at 10:38, Andreas Pakulat wrote:
>
> >On 29.06.06 10:26:45, Helmuth Stockmann wrote:
> >>So basically I get the same, checking out "webapp_internal" would
> >>give me
> >>all sources from the internal directory as well as the shared
> >>directory.
> >>
> >>==== SO FAR SO GOOD. SO WHAT IS THE PROBLEM THEN? ====
> >>
> >>The problem is that when I have got a module "webapp_internal"
> >>checked out
> >>and I make changes to sources in the shared directory, i have to
> >>do an
> >>explicit commit on the shared subdirectory. In the CVS workspace,
> >>I could
> >>simply issue a commit at the top level and ALL changes would be
> >>checked in
> >>to the repository, from both the internal module as well as the
> >>shared
> >>module.
> >
> >Without beeing a subversion geek, I'd say: Get used to it, that's the
> >way subversion works.
>
> Being a Subversion geek, I'd say the same thing. That's how it works.
Being a SCM geek, I'd say ignore the previous two remarks. If there are
dependencies between two components of your software, then you really
want atomic commits across both of them. Otherwise you can end up with
an inconsistent repository.
The fact that you don't get atomic commits when using externals is a big
hint that using them this way is not what the creators of subversion
intended. Indeed, the latest version of the book recommends that you
specify a revision in the externals property, meaning that the external
reference is intended to point to a snapshot of third party code. It
isn't meant to be like a soft or hard link in a filesystem.
If you want the layout of your working copy to differ from the layout
in the repository, then use `svn switch'. If you want this structure to
apply to every working copy, write a script that does the switches for you.
A special property that does this switch automatically would be a good
feature, IMHO.
Cheers,
Mark.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 3 05:51:13 2006