> >> It definitely makes sense to pin external revisions when tagging.
> >> I would even go as far as saying that externals *always* should
> >> be pinned.
> > It totally depends on what the external is. In our case,
> > we use "internal externals" for shared library projects.
>
> Well, no. It doesn't matter. Having a "floating" external will always
> give you a broken history. No way around that.
>
> For example: A colleague tells you of a problem that was detected in
> revision 3518 of your main product. This product depends on a number
of
> shared libraries included by "floating" externals. You update your
> working copy to that revision to be able to debug the error. However,
> the problem might well not be reproducible on your working copy. If
the
> error occurs in combination with a specific revision of one of your
> shared libraries, and that library has changed since your colleague
> checked it out, you're out of luck.
>
> Keep your externals pinned and your history happy, that's my
suggestion.
> (Even for "internal externals".)
>
> Hans-Emil
My 2 cents, when working on code, we want the choice to use a fixed
(pinned) version of an external, or a floating version of an external.
The fixed version gives me the confidence that my code should always
compile and I don't have to take the latest version. However we have a
lot of people working on the shared code (bug fixing and adding
features) and I want to have the latest code up until I release for some
shared projects. When I release (by applying a tag) a hook script is
used to check all externals have fixed revisions. If some externals are
not fixed the commit will fail and a manual update of the externals must
happen. Some automation of this would be great. Probably not fixing it
to the head though, but instead fixing it to the current rev I have in
my working copy would be more correct.
Further to this, if I am using a fixed external project, and the fixed
link does not point to the head of the repository some improvements
could be made around updating the fixed revision number when I change
the shared code in my project.
The use case is, someone comes to my desk to ask for a bug fix to shared
code. I can bring that shared code to the tip, make the change and
commit it back to the repository. It would be nice if tortoise could
check the parent directories to see if the code I am committing is
brought in to the project as an external and prompt me to update it if I
want. This would mean that I can take the bug fix automatically without
having to do the commit, and then updating my project external revision
number. This is a bit harder to do, but would make life easier. Note
with this functionality, the user should be presented with a choice of
updating the fixed revision number as I may not always want to take the
new code.
Sorry this was more like 10 cents than 2 cents.
Scott
P.S. The use of externals seems to be the only gripe around work here.
But I think it is more teething problems as people have to move from the
way they use to work with the last version control system.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Apr 12 22:54:22 2007