bzr-eclipse team mailing list archive

[Piotr Piastucki <piastucki@xxxxxxxxx>]

Ok, Adding support for shared repositories sounds good. We can
probably suggest initializing a repository at the workspace level so
that all projects in the workspace will take advantage of the shared
repo.

As mentioned before there is a bzr command that should transform a
lightweight checkout into normal one (bzr reconfigure --checkout), but
it always fails with a cryptic error message - see also
https://bugs.launchpad.net/bzr/+bug/562896. I have already implemented
the code to ask the user and run bzr reconfigure but since it fails I
disabled it. It is still in main bzr-eclipse branch though.

I also do not want to ask the users to migrate during an upgrade
therefore I added a warning to inform them that the support for
lightweight checkouts will be removed in future versions. This way
they have plenty of time (months) to migrate.
Unless we find a reliable way to perform the migration automatically
(with no scary error messages and no data loss) manual migration seems
to be the only acceptable option here.

Since the warning message is rather annoying we will probably find out
the number of people using LW checkouts pretty soon too :) They will
either migrate to get rid of the warning or raise questions/tickets.
We can actually change the warning message and explicitly ask the
users to contact us regarding LW checkouts when in doubt.


Regards
Piotr

On Tue, Sep 24, 2013 at 2:10 PM, Alexander Taler <dissent@xxxxxxxx> wrote:
>
>
>> I am not sure if I was clear enough about LCs in my last email, so let
>
> You were pretty clear :)
>
> I agree with not supporting a feature if it's broken, and I
> understand why Eclipse would excarcebate the problem.
>
> But I think there's value in not copying the entire repository
> for every branching operation.  This is one reason to prefer
> Bazaar over Git.  Therefore I would like to see phasing
> lightweight checkouts happen at the same time as support for
> shared repositories.  Shared repository setup could fit into the
> project creation wizard as an advanced option selection.
>
>> 1) ask the users to migrate LCs manually (currently I cannot see a way
>> to provide an automated migration that will satisfy everyone)
>> 2) provide enough information: useful links, wiki page etc.
>> 3) answer any questions related to the migration
>> 4) avoid introducing any kind of partial or dodgy LC support to the
>> code unless it turns out to be absolutely necessary (e.g. requested by
>> the majority of users)
>
> Manual migration steps during an upgrade are a horrible user
> experience.  I think we need to explore automated options for
> migration a bit more; probably the simplest approach is to have a
> process which converts a LW to a regular checkout, and prompt the
> user to do it.  But leave the option for the user to find their
> own migration solution instead.
>
> Perhaps the first question is if there's a way to find out how
> many people use LW checkouts.
>
> Alex
>
> --
> idereal | deliver                       http://idereal.co.nz/
> Get your software to market sooner      022 659 0282