On 9/15/06, Anders Norman <Anders.Norman@projectiondesign.com> wrote:
> Yes I know and agree, but only for frameworks that have reached some
> level of completeness. We are developing both the framework and two
> projects which use it simultaneously, hence we do indeed want the latest
> and greatest at all times, but we do also want the ability to fetch an
> old revision now and again.
>
> With
> framework -r100 svn://svn/repos/framework/trunk
> one fetches the rev 100 of the framework trunk, but if one had, as I
> suggested before a way of specifying the current local revision in this
> property, like:
> framework -r%REVISION% svn://svn/repos/framework/trunk
> one would please both camps.
>
> Anders
>
> -----Original Message-----
> From: John Waycott [mailto:javajohn@cox.net]
> Sent: 14. september 2006 15:54
> To: Anders Norman
> Cc: Gale, David; users@subversion.tigris.org
> Subject: Re: externals question/suggestion
>
> Anders Norman wrote:
> > That is true, but I wouldn't want all my users to manually go through
> > this extra step. Also, when doing maintenance development on old
> > projects, one may have forgotten all the manual steps it took to
> acquire
> > the source code. One should only do:
> > svn co svn://svn/repos/project_a/trunk
> > make
> >
> > But thanks for the suggestion. I hadn't thought of that :-)
> >
> > Anders
> >
> >
> >> It would be nice if I could set the externals property to something
> >> like:
> >> externals:
> >> framework -r%REVISION% svn://svn/repos/framework/trunk
> >>
> >> to make the external reference actually fetch the same revision as
> the
> >> project it's being used by. This would of course require that the
> >> external and the 'externee' reside in the same repository.
> >>
> >
> > Another option would be to add an empty framework directory to
> > project_a/trunk and project_b/trunk, and then svn switch it to point
> to
> > the framework/trunk directory after checkout. At that point, you have
> > the structure you want, with no externals definitions at all; updating
> > to a specific revision will hit all directories, including the
> framework
> > one.
> >
> > Yes, it takes an extra step or two to set up, but once you do,
> > everything works transparently.
> >
> > -David
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
> One of the drawbacks to using svn:externals which point to a trunk is
> that you lose the ability to reproduce a previous source tree. A way
> around this is to always point your svn:externals to a tag. There's a
> little more bookkeeping required because you have to update each project
>
> with the new tag from the framework. However, I would argue that this
> control is an advantage because you will always know exactly what
> version you got. You also can control when you get the next version of
> framework. Many times you may want to hold off on getting changes to the
>
> framework because you aren't ready for them. If the svn:externals points
>
> to the trunk, you will always get the latest framework no matter if you
> are ready for it or not.
Why not just make the framework into a library, and make install it.
We have a number of apps that are dependent on a shared widget
library. The widget library is constantly changing. We do not use
externals. Instead, we simply make install the widget library based
on what ever particular revision you have checkedout. Your apps then
link with the installed version. We do this all the time, and our
development environment is very dynamic due to apps and SDK being
developed at the same time.
Sean
>
>
> -- John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 15 07:30:27 2006