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

RE: Extend svn:externals to support files (issue 937)

From: Trent Nelson <tnelson_at_onresolve.com>
Date: 2007-01-18 15:12:52 CET

From: Daniel Rall [mailto:dlr@collab.net]:
> On Wed, 17 Jan 2007, Trent Nelson wrote:
> >
> > Regarding: http://subversion.tigris.org/issues/show_bug.cgi?id=937
> > E.g.:
> > svn:externals:
> > bin/tcnative-1.dll
> ...
> > Karl suggested two possible implementations (again, way back in
> > either allow svn:externals to refer to files (and handle as dirs are
> > handled), or change .svn/entries to refer to files in other
> > repositories.
> >
> > Is either of these still plausible? I've lurked around the
> > code with these two points in mind and have a few ideas/questions,
> > I'd like to hear other subversion developers' thoughts on this issue
> > first.
> Don't you need to do both?

Well, yeah, that's one of the things that I wanted to clarify. What's
the general consensus towards hacking libsvn_wc to support multi-repo
entries? From what I could see this would have a wide ranging impact on
lots of areas of the code -- would this be acceptable?

I think if we were to avoid .svn meddling for external files, you'd get
behavior along the lines of:

% svn pl -v
   bin/tcnative-1.dll http://svn.foo.com/repo/tags/tcnative-1.1.8.dll

% svn update
Fetching externals into 'bin/tcnative-1.dll'
A bin/tcnative-1.dll

% svn st
? bin/tcnative-1.dll

% svn update
Fetching externals into 'bin/tcnative-1.dll'
U bin/tcnative-1.dll

i.e. each update forces a fetch from the RA layer as there wouldn't be
any way to determine if the file has changed. (There's no way to
retrieve a target's md5sum via the RA layer, right?)

I'd be content with this, at least as an interim solution.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 18 15:14:06 2007

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