On Tue, May 01, 2007 at 07:36:11PM +0100, Andy Parkins wrote:
quoted text
> On Tuesday 2007, May 01, Chris Shoemaker wrote:
> 
> > > Actually that is an interesting point that Chris makes.  Isn't the
> > > svn:externals property revision controlled on the parent directory?
> > > So each change to it is actually recorded in the revision history
> > > of the parent project.
> >
> > Yes and yes.
> 
> Yes and no.  Think of svn:externals as a file in the parent repository; 
> it contains
> 
>  directory-name URL
> 
> Now, changes to that file _are_ tracked, in that if I changed the URL 
> that change would be recorded in the parent repository.  However, 
> nowhere is the revision of the external recorded.  Subversion always 
> fetches the latest revision at that URL.

That's only true when the revision is not specified in the external.
The repo you track may not do that, but it's not uncommon to do so.
And, as I think you're pointing out, it's the only way to get any sort
of reliable information about the relationship between the parent and
the external.

I think it would probably be undesirable for git-svn to attempt to
convert "floating" externals into well-versioned submodules, since
they're not even well-versioned in the svn repo.  However, handling
the "locked-down" externals is quite another thing.

quoted text
> 
> > > And if every svn:externals URL included the
> > > exact version of the other project to include, aren't svn:externals
> > > then more-or-less like the subproject link support, except they
> > > also include the URL?
> >
> > Just to clarify, my point was just that Andy's setup seems to assume
> > that the externals don't specify a revision.  If they do, maybe
> 
> They don't.  If they did, they'd be just as useful as git's submodules.
>
> > git-svn can map the externals into subprojects.  Is this what
> > you're thinking?
> 
> Well, I'm thinking that that information /can/ be reconstructed from the 
> revision date information - kind of - the problem is that there is no 
> way to know when the parent updated the module.   svn:externals really 
> is just a quick way of doing
>  $ cd submodule
>  $ svn update
> That's it.  That's all you get.  We could guess that when the parent 
> module was at date YYYY-MM-DD, that the submodule would be at that same 
> date - but who knows?

svn users who want the externals to meaningfully define the version
relationship between the parent and the project already have to use
externals that specify a revision.

-chris
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html