You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C.A.T.Magic" <c....@gmx.at> on 2004/07/22 17:09:16 UTC
Re: PATCH: $Header$ handling + existing BUG of $HeadURL$ now also
in $Header$?
Alexander L. Belikoff wrote:
> $Header$ has very clear advantages over $Id$.
in SVN, the $Id$ keyword has lost a bit of information
in comparison to CVS: the _branch_ of the file.
SVN:
$Id: file.txt 2 2004-07-22 16:22:50Z cat $
CVS:
$Id: file,v 1.259.2.2 2003/12/04 20:38:11 cat Exp $
in svn's $Id$ its hard (or impossible?) to tell if
the file came from trunk or from a branch.
in cvs it is clearly visibly because you see
the 4-digit version number "1.259.2.2".
but there is also a negative side to using $Header$ in SVN:
because $Header$ alsways contains the full repository path,
it is also containing the 'TAG' path.
$Header: /Tags/foo-20040501/test.txt,v 5 2004/07/22 16:39:38 cat Exp $
$Header: /Tags/foo-20040608/test.txt,v 8 2004/07/22 16:39:38 cat Exp $
this means that you get different file content for _all_ files,
dependent on the tag you used to checkout the file,
even if the rest of the file is identical.
In CVS the path and version always remains the same if the file is
unmodified.
does this patch ensure that svn switch visits ALL files containing
$Header$ and update them correctly?
$HeadURL$ is already buggy in this regard:
( the following assumes Repos/file.txt and
a tag created from it as Repos/TAG/file.txt
exists )
#>cat file.txt
$HeadURL: file:///Repos/file.txt $
#>svn switch file:///Repos/TAG/file.txt file.txt
#>cat file.txt
$HeadURL: file:///Repos/file.txt $
^^^^ but this should now be Repos/TAG/ !
#>del file.txt
#>svn update file.txt
#>type file.txt
$HeadURL: file:///Repos/TAG/file.txt $
^^^^ only works if file is deleted first.
======
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling + existing (behaviour) of $HeadURL$
now also in $Header$?
Posted by John Peacock <jp...@rowman.com>.
C.A.T.Magic wrote:
> If its critical to regenerate 100% identical files,
> there is probably only one solution:
> tag, delete_wc / fresh checkout tag, build, release it.
>
I would actually say
tag, export, build, test, release
would be the most appropriate workflow.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling + existing (behaviour) of $HeadURL$
now also in $Header$?
Posted by "C.A.T.Magic" <c....@gmx.at>.
John Peacock wrote:
>
> You misunderstand how keywords work in general. The client code only
> interprets a keyword at the point in time the file is changed (either
> through an update, checkout, or export). There is no code that walks
> through the WC and re-expands keywords based on some external event _if
> the file itself hasn't been changed_.
I absolutely understand _why_ it is the way it is
(mostly speed reasons)
but it means that one gets slightly different files,
dependent on the method used to checkout a WC.
at least 3 methods:
-) fresh checkout trunk at revision x
would contain "/trunk/foo"
-) fresh checkout a tag of that trunk revision x
would contain "/trunk/tag/foo"
-) checkout trunk and switch to that tag
would contain either "/trunk/tagxyz/foo"
or "/trunk/foo" depending on the WC's
prevous content.
If its critical to regenerate 100% identical files,
there is probably only one solution:
tag, delete_wc / fresh checkout tag, build, release it.
:-)
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: $Header$ handling + existing BUG of $HeadURL$ now also
in $Header$?
Posted by John Peacock <jp...@rowman.com>.
C.A.T.Magic wrote:
> but there is also a negative side to using $Header$ in SVN:
> because $Header$ alsways contains the full repository path,
> it is also containing the 'TAG' path.
> $Header: /Tags/foo-20040501/test.txt,v 5 2004/07/22 16:39:38 cat Exp $
> $Header: /Tags/foo-20040608/test.txt,v 8 2004/07/22 16:39:38 cat Exp $
>
> this means that you get different file content for _all_ files,
> dependent on the tag you used to checkout the file,
> even if the rest of the file is identical.
That's a feature, not a bug. If you export from a tag, any keywords which
reflect the path in the repository must display the current location in the
repository, regardless of whether the file has changed from wherever it was
copied from (TRUNK is not special in this regard).
> In CVS the path and version always remains the same if the file is
> unmodified.
And that's *loss* of information.
>
>
> does this patch ensure that svn switch visits ALL files containing
> $Header$ and update them correctly?
You misunderstand how keywords work in general. The client code only interprets
a keyword at the point in time the file is changed (either through an update,
checkout, or export). There is no code that walks through the WC and re-expands
keywords based on some external event _if the file itself hasn't been changed_.
> #>cat file.txt
> $HeadURL: file:///Repos/file.txt $
>
> #>svn switch file:///Repos/TAG/file.txt file.txt
>
> #>cat file.txt
> $HeadURL: file:///Repos/file.txt $
>
> ^^^^ but this should now be Repos/TAG/ !
'switch' does not imply 'update' here; the file hasn't changed between TRUNK and
TAG, so the client does not update the file (i.e. re-expand the keywords).
>
> #>del file.txt
> #>svn update file.txt
> #>type file.txt
> $HeadURL: file:///Repos/TAG/file.txt $
>
> ^^^^ only works if file is deleted first.
Now you have forced the client to regenerate the keyword (by deleting the file).
'svn up' is not sufficient on it's own to regenerate keywords; whether it
should be is a matter of debate. I'm incline to think it should, but that might
entail much more client-side activity than would seems fruitful.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org