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.
-- John
---------------------------------------------------------------------
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:19:44 2006