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

Re: svnversion weirdness with svn:externals

From: <kfogel_at_collab.net>
Date: 2005-06-24 18:29:29 CEST

Andreas Schultz <andreas.schultz@gmail.com> writes:
> After upgrading a svn server from 1.1.4 to 1.2, doing a svnversion in
> a working copy that has svn:externals, reports as mixed version based
> on the versions of the working copy and the external, e.g. 352:422M.
>
> This very same problem that had been discussed and solved almost two
> years ago here:
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=48985
>
> Any ideas how to get the old behavior back?

In other words, you want the pre-0.27 behavior? It looks like the
sequence has been:

   * Up to and including 0.27, svnversion ignored svn:externals.

   * From 0.28, until sometime before 0.32.1, it payed attention to
     svn:externals.

   * Sometime between 0.32.1 and 1.1.4, it started ignoring
     svn:externals again.

   * Sometime between 1.1.4 and 1.2.0, it started paying attention to
     svn:externals again.

That's pretty amazing :-).

The "M" on the end of your example, "352:422M", is extraneous, by the
way, right? The real issue here is the presence of the ":422", and
whether the external happens to be locally modified ("M") or not is
irrelevant.

Current head of trunk (r15159) still has the buggy behavior:

   $ svn up
   
   Fetching external item into 'svntest'
   External at revision 15159.
   
   At revision 1428.
   $ svn st -q
   
   Performing status on external item at 'svntest'
   $ svnversion
   1428:15159
   $

I agree that this is a bug, or at least a suboptimal behavior. An
acceptable solution would be to just ignore svn:externals entirely.
An even better solution might be to print "E" at the end to indicate
that externals are present in the working copy, thus:

   $ svnversion
   1428E
   $

Would you mind opening an issue for this bug, and pointing to this
mail thread from the issue? If you don't have time, that's fine, just
let me know either way. (And of course, if you have time to make a
patch to fix the bug, that's always great!)

Thanks for the report,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 24 19:14:22 2005

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