Nick Seigal wrote:
>>Alex R. Mosteo wrote:
>>
>>
>>>[Nick Seigal:] ... a tag of my project containing
>>>externals should only be containing externals pointing at other tagged
>>>and unchanging repository codelines. These should never be changed or
>>>deleted (hence the idea of a "tag"), and I can insure this, since we
>>>maintain our own vendor-library and internal-library branches and
>>>their policies ...
>>
>>Thanks Nick, I've too arrived to this conclusion. My case is a bit more
>>annoying because I'm modifying the external library too from the main
>>project, so I can't link to a "frozen" revision of the library ATM. Thus
>>when I make a milestone for the project, I must go to make tags for all
>>the external libraries involved and make new external ad-hoc properties
>>for the milestone tag.
>
>
> Of course your method does *work* (with some manual effort). I think a more
> de-coupled strategy may work better. I suggest that, if possible, you *not*
> modify the external library "from the main project". This was my old
> working method and getting rid of it was key in my improving my source
> control strategy.
I have thought about this too. I think this is not possible for me ATM,
since the library and the main project are evolving too closely so I
need to work HEAD to HEAD... except for when I want to make a milestone
and frozen a version.
In other words, I don't think it matters now if I work in the library
from the inside or the outside... When the library is reaching a more
stable form I will switch to your recommended procedure.
> It seems to me that a good process rule is that shared products should be
> developed in their own workspaces. Personally, I find it useful to create
> custom test-clients to develop and test my shared libraries against, so that
> I am assured that each is truly going to work for more than just the one app
> I've linked it to so far.
Fine thinking.
> If you wish to, you can set up both workspaces (e.g. those of the core app
> and a library it depends on) to "external" each other at the appropriate
> branches and revisions, and use the main app *as* the "test-client" for the
> shared library.
>
> If the library is not going to be shared (but seperating it from the core
> app is just for modularity in a multi-tier deployment for example), then I
> put it in the same working directory heirarchy as the core app (in a
> subfolder) *but* I wouldn't then need externals as I would have its
> repository in a subfolder of the core app's repository.
That's what I did with this library, too, until it has become needed in
two different projects. Now, you may think that I'm going to run in
troubles because the coupled dependency I've mentioned early. The thing
is that I'm extending a new part of the library, so no conflict can
arise between the two projects, but I don't find sufficiently justified
to split the library in two, as they're part of a common framework.
> The rules I follow for minimizing dependency issues are:
>
> 1. If an internally developed library is part of one project and not
> planned for use in any other, then it should be put somewhere under the same
> workspace and repository tree so that it can be developed and versioned
> along with the main project.
>
> 2. If an internally developed library is to be shared between multiple
> projects, then it should be developed from its own workspace and have its
> own repository and versioning. From the perspective of project developers,
> it should be treated like a closed-source vendor drop. To use it, link it
> to the main projects via externals pointing at tagged release versions of
> the library. Project developers may also be library developers where
> appropriate and authorized.
>
> 3. If an external vendor library is open-source, treat it as a vendor
> drop. To use it and develop against it, merge it into the main project.
> Merge patches to the library back to the vendor drop (or even back to the
> vendor) where appropriate and authorized. (We don't do a lot of this
> yet...)
>
> 4. If an external vendor library is closed-source, treat it as a vendor
> drop. To use it, link it to the main projects via externals pointing at
> tagged release versions of the library. (We do a lot of this though!)
>
> These rules reflect a strategy that is still in its infancy. We need to get
> more experience with it to identify its flaws. It does seem to require a
> bit more on the client-side in terms of workspaces, but it is more clearly
> organized in terms of workflow and responsibilities and doesn't require
> complex or manual kludges to the externals.
These rules mimic what I've done till moment (I'm at 3) and what I would
probably do (steps 4 hasn't been an issue here). Thinking of step 2, I
still wonder if it is not too cumbersome to maintain the external
references when there are a) a lot of external dependencies, and b)
some/most of these are changing rapidly (and for some reason you can't
stay with older versions).
Not that I can see any other option ATM.
Thanks for your detailed comments,
Alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 19 11:49:25 2005