Feature Request: 'bzr mv --after' to tell bzr that file(s) have already been moved in the working tree

[Hanns-Steffen Eichenberg]

On 11/4/06, Marius Kruger <amanic at gmail.com> wrote:
>
> On 11/3/06, Hanns-Steffen Eichenberg <scameronde at googlemail.com> wrote:
> >
> > From our 100 developers about 40 are programming Java using Eclipse. No,
> > no. I am not calling for an Eclipse Plugin :-) We know how to operate on the
> > command line. But it is very common work to refactor code from within
> > Eclipse. This includes moving and renaming of files. What we need is a way
> > to tell bzr, that a file under version control HAS BEEN MOVED. It is no
> > option to move the file using bzr, since this would interrupt the workflow
> > in Eclipse and would make unnecessary synchronizations necessary. The dvcs
> > Mercury uses the option '--after' to tell the vcs to update the repository
> > to reflect the actual situation in the working tree.
> >
> > I really would like to see an option like '--after' for the mv command.
> > It shouldn't be too complicated (in fact i hacked bzr 0.13.0dev0 to
> > accept the --after option for the mv command and just update the repository,
> > not the working tree. I do not know if i have done it correct, but it works
> > for me). It works like:
> >
> >   $ bzr mv text1.txt text2.txt --after
> >
> > telling bzr that someone has moved test1.txt to text2.txt.
> >
> > Has this feature been discussed before? Is the idea good or am i missing
> > something that makes it just plain silly?
> >
> >
>
> hi,
> Being a eclipse user I know your pain!
> It is probably the most anoying bzr problem for me at the moment.
> We have discussed it before on the mailing list, and the is a bug noted in
> launchpad (sort of):
> https://launchpad.net/bugs/5158
>
> But yes it will make me soooo happy if someone will just fix this, even if
> it is with a flag for now,
> we could always continue to debate if it should be automatic in future.


My current patch (draft version, not made public yet) uses a flag or the
following logic:

  - source present and versioned, target not present and not versioned:  mv
file and change repo (regular mv)
  - source not present and versioned, target present and not versioned:
only change repo (new mv)
  - source present and versioned, target present and not versioned: you have
to use the flag or it is an error
        (for situations like:
                   mv a b; touch a; bzr mv a b  ==> ERROR
                   mv a b; touch a; bzr mv a b --after  ==> OK
         )


also see the following email posted on the mailing list.
> regards
> marius
>
>
> ---------- Forwarded message ----------
> From: Michael Ellerman <michael at ellerman.id.au>
> Date: Jul 20, 2006 2:23 AM
> Subject: [Bug 5158] Re: rfc: don't treat missing files as deleted
> To: amanic at gmail.com
>
> It should be an easy patch to change bzr mv to cope with the source and
> destination already being moved. It just probably requires a little
> thought as to whether it should spit out a warning, or require a special
> flag etc. It'd be a good first patch for some keen bzr newbie.


Hey, that is me ;-)


I've got the beginings of an auto-rename plugin at:
>
> http://michael.ellerman.id.au/bzr/plugins/auto-rename
>
> It tries to match files based on their SHA1, and if that fails does a
> fuzzy match based on the number of lines changed between the two
> versions. It needs a bit of polish, but it's 50% there.


I thought about something like this, too. Good that there seems to be a
starting point. I will have a look at the code as soon as i have some time.
Maybe it is something that i can do.

I think when using the fuzzy match the user must be the one who finally
decides
if a match is correct or not. Maybe the auto-rename could open an editor
with
its suggestions. That would allow for easy control and confirmation of mass
renames.

Ciao,
  Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20061105/3ec7678c/attachment.htm