treats expanded svn keywords as changes

[Wouter van Heyst]

I just did a fresh svn checkout, and then tried to see if bzr would work with a native svn checkout. A `bzr status` fetched some revision info and a fileid map as expected, but it confused me when it said there were modified files. This was a new checkout!

It turns out all the changes are of a nature $Id$ -> $Id: file rev date name$ etc.

[Jelmer Vernooij (jelmer)]

On Thu, 2007-01-25 at 13:33 +0000, Wouter van Heyst wrote:
> Public bug reported:
>
> I just did a fresh svn checkout, and then tried to see if bzr would work
> with a native svn checkout. A `bzr status` fetched some revision info
> and a fileid map as expected, but it confused me when it said there were
> modified files. This was a new checkout!
>
> It turns out all the changes are of a nature $Id$ -> $Id: file rev date
> name$ etc.
This can only be fixed by either adding keyword support to Bazaar (fuzzy
diffs) or by modifying the bazaar working copy file access functions to
replace $Id foo$ -> $Id$. Since the latter is rather ugly, I'd rather
wait for keyword support.

Cheers,

Jelmer
--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/

[Wouter van Heyst (larstiq)]

On Thu, Jan 25, 2007 at 10:58:35PM -0000, Jelmer Vernooij wrote:
> On Thu, 2007-01-25 at 13:33 +0000, Wouter van Heyst wrote:
> > Public bug reported:
> >
> > I just did a fresh svn checkout, and then tried to see if bzr would work
> > with a native svn checkout. A `bzr status` fetched some revision info
> > and a fileid map as expected, but it confused me when it said there were
> > modified files. This was a new checkout!
> >
> > It turns out all the changes are of a nature $Id$ -> $Id: file rev date
> > name$ etc.
>
> This can only be fixed by either adding keyword support to Bazaar (fuzzy
> diffs) or by modifying the bazaar working copy file access functions to
> replace $Id foo$ -> $Id$. Since the latter is rather ugly, I'd rather
> wait for keyword support.

Yeah, I was afraid of the complications, but imho it does need to be
tracked. I'd give keyword support in core a very small chance.

Wouter van Heyst

[Jelmer Vernooij (jelmer)]

On Thu, 2007-01-25 at 23:10 +0000, Wouter van Heyst wrote:
> On Thu, Jan 25, 2007 at 10:58:35PM -0000, Jelmer Vernooij wrote:
> > On Thu, 2007-01-25 at 13:33 +0000, Wouter van Heyst wrote:
> > > It turns out all the changes are of a nature $Id$ -> $Id: file rev date
> > > name$ etc.
> > This can only be fixed by either adding keyword support to Bazaar (fuzzy
> > diffs) or by modifying the bazaar working copy file access functions to
> > replace $Id foo$ -> $Id$. Since the latter is rather ugly, I'd rather
> > wait for keyword support.
> Yeah, I was afraid of the complications, but imho it does need to be
> tracked. I'd give keyword support in core a very small chance.
There is a spec for it, see
https://blueprints.launchpad.net/bzr/+spec/bzr-keyword-expansion

I can understand why you'd like it fixed, though I'd rather invest time
in proper support in bzr core than an ugly workaround in bzr-svn. Same
situation applies to svn:ignore.

  status confirmed

Cheers,

Jelmer

--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/

[Jelmer Vernooij (jelmer)]

This needs to be fixed in bzr first.

[Robert Collins (lifeless)]

Could you enlarge on what is needed in bzr?

[Jelmer Vernooij (jelmer)]

well, afaik only "rules" are supported at the moment, there's no keywords plugin yet.

Other than that, the problems mentioned in bug 145155 seem appropriate here as well since it's a similar issue.

[Ian Clatworthy (ian-clatworthy)]

A keywords plugin does not exist though it needs a branch supporting content filtering. See https://launchpad.net/bzr-keywords.

Let me know if there's things the keywords plugin needs to do to better support svn interoperability. Note that it doesn't support the same keywords as Subversion - it supports one that make sense for Bazaar. Perhaps it should contract *all* keyword expansions though in nominated files, whether it knows about the keyword or not?

[Ian Clatworthy (ian-clatworthy)]

That's was meant to read ... does *now* exist.

[Ian Clatworthy (ian-clatworthy)]

Checking the help and code for bzr-keywords, it does indeed compress all detected keywords. So if subversion expands a keyword, Bazaar should do the right thing and store the $Keyword$ form regardless of whether Bazaar supports that keyword or not.

I've just tweaked the expansion logic in the keywords plugin as well. It will now replace keywords it knows about and ignore the expansion for the keywords it doesn't (rather than replace them with an empty string). I think that should imporve interoperability with Subversion IIUIC.

[Jelmer Vernooij (jelmer)]

Hi Ian,

Cool, I hadn't seen the keywords plugin yet ! I'll give it a try.

The problematic thing for bzr-svn at the moment is the fact that .bzrrules is versioned as part of the revision tree.

This causes two lists of rules to end up in subversion and that makes pulling in changes from svn hard because the two would have to be merged.

The .bzrrules files would end up in Subversion, potentially annoying other Subversion users like bzr-svn file properties have done in the past.

.bzrrules describes the whole tree, and that will affect the performance of per-file access since generating .bzrrules on the fly requires bzr-svn to query every single file in the tree in svn.

[Ian Clatworthy (ian-clatworthy)]

Jelmer Vernooij wrote:

> The problematic thing for bzr-svn at the moment is the fact that
> .bzrrules is versioned as part of the revision tree.

OTOH, access to it is isolated by a new API that I've got a
patch up for - get_special_file. bzr-svn *could* reimplement that
to load/save the data somewhere more private I guess. Keep in mind
though that the driving reason for putting it in the tree is to
ease merging, etc.

> The .bzrrules files would end up in Subversion, potentially annoying
> other Subversion users like bzr-svn file properties have done in the
> past.

Maybe. A simply workaround is to add .bzrrules to .svnignore?

> .bzrrules describes the whole tree, and that will affect the performance
> of per-file access since generating .bzrrules on the fly requires bzr-
> svn to query every single file in the tree in svn.

I'd strongly recommend against generating this on the fly each and every
time. Instead, I'd suggest a workflow where a new command generates it
once and it is manually maintained after that. It's not perfect but it's
the sort of compromise necessary using multiple tools on the one tree IMO.

Ian C.

[Jelmer Vernooij (jelmer)]

It's not the access to this file that's the problem - it's the fact that it lives in the revision tree. This means it has to be pushed into Subversion, otherwise we hit problems when round-tripping.

Appending the file to svn:ignore doesn't help since svn:ignore is only evaluated at the working tree level, not when fetching between branches.

If .bzrrules isn't generated on the fly it means keywords won't work out of the box, and it becomes impossible to easily track a subversion branch that uses keywords (since the local branch will diverge because it has to have .bzrrules added to it).

It also means that there are two lists of ignores to keep up to date, and thus that pushing files with keywords into Subversion becomes impossible without manually patching things up afterwards using the svn client.

I understand that having .bzrrules in the working tree at the same level of .bzr is useful for merging and the like, but would rather see it be a checkout of a versioned file that isn't part of the inventory.

[Robert Collins (lifeless)]

On Fri, 2008-07-25 at 17:40 +0000, Jelmer Vernooij wrote:

> I understand that having .bzrrules in the working tree at the same level
> of .bzr is useful for merging and the like, but would rather see it be a
> checkout of a versioned file that isn't part of the inventory.

FWIW so would I - its precisely this sort of problem that we had
with .bzrignore that had me arguing against it being a user visible
file.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.