[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with the present handling of svn:externals

From: John Dubery <j-d_at_ukonline.co.uk>
Date: 2005-02-19 20:48:52 CET

Hi,

> I think that's a bit judgemental. :-) You're the first person to ever
> notice or care that this "critical" feature of svn:externals isn't
> available.

OK, judgemental isn't the intention - though I guess I was rather direct.
:-(
Please accept apologies for appearing judgemental. :-| I have become a SVN
fan -
it works very nicely in the bulk of cases (at work and at home). All said
and
done, I see a lot of potential and I'm wanting see it's use grow and grow.
Thanks for the software.

My comments came out of having a situation at work that I'd have loved to
have been able to use svn:externals for - but it just wasn't viable with the
current operation (the external common files were changing much too much
for either fixed versioning or repeated tagging to be useful).

I'd originally thought I was looking at a suggestion for SVN rather than
saying
that there's a defect in it; I changed my mind on thinking the thing through
carefully. The core point for me is (quoting my original post on this issue)
"One fundamental of a version control system (to my understanding) is that
it
can reproduce any past version of a fileset on command." Is it right for a
command like "svn export -r 54 ...." (which appears to request a fixed
revision) to return different filesets at different times?

> ... I'm
> not entirely convinced that an external always having the same revision
> number as its parent project is any less of a "moving target" than just
> tracking HEAD.
I do hope I can convince you guys; I think (from things said at work) you'll
need it for SVN to be adopted as widely as possible. I suspect that this
issue will cause people to think twice about adopting SVN for some large
developments and then go elsewhere, rather than hang in with SVN.

> .... Very often externals point to completely
> different repositories, in which case the feature you propose be
> meaningless.
Quite so - all that could be used would be a date-time value, which
has a lot of other dangers and may well not be worth even trying.
Perhaps the best default behaviour here is to require either a fixed
version or and explicit HEAD request.

------------------

Enough ... blabbing on isn't going to achieve anything useful.

I accept that it's not my software and I haven't time to offer to fix the
code;
all I can do to help SVN on its way is encourage its use and make
comments where I believe there's a benefit. It's up to you guys to decide
whether I'm right on this one, and if so make whatever changes.

------------------

cheers

John Dubery

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 19 20:48:01 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.