[MonoDevelop] Feedback Request - User Data Locations

[Michael Hutchinson]

On Mon, Feb 14, 2011 at 9:42 AM, IBBoard <ibboard at gmail.com> wrote:
> On 14/02/11 03:39, Michael Hutchinson wrote:
>>
>> We're planning to move the locations that MonoDevelop stores user
>> data, to make it more idiomatic for each of the major OSes that MD
>> runs on, to make it clearer what should be backed up and what can be
>> deleted safely, and to allow roaming profiles to work on Windows.
>>
>> I've documented the planned locations at
>> http://monodevelop.com/Developers/Articles/User_Profiles
>>
>> Please let me know if there are locations that would make sense, and
>> why they would be better.
>>
>
> It generally looks sensible for the Linux side of things. For my apps then
> I've just used the built-in .Net default paths.

Yeah, a note on that - when I was looking at that I realized that
ApplicationData and LocalApplicationData have the wrong semantics on
Linux. The former maps to "config" and the latter maps to "data",
instead of the remote/local distinction. Because of that, I avoided
using them, and implemented the XDG spec directly.

> The only comments/questions I'd have are:
>
> 1) For the sake of tidiness (reducing folders at a given level on a user's
> machine) would it not be better to use "MonoDevelop/version" rather than
> "MonoDevelop-version"? That way the user always gets just one MD folder

I considered that, but I think my way makes it clearer to the user
that old profiles still exist and can be removed. It also implies that
we have versioned profiles, rather that a profile with versioned data.

> 2) Would it be possible to include a forced migration, in case the first one
> failed or generally didn't include everything?

This is a minor use case IMO and probably not worth complicating the
UI. However, by removing MonoDevelopProperties.xml from the target
profile, you can force a migration.

Something I didn't implement support for is for migrating the user
data of addins that are installed after MD is first run, but this
would be easily fixable by keeping a list of migrated addins in the
properties store and checking loaded addins against it.

It might be worth thinking about a GUI in preferences for deleting old
profiles and clearing caches.

-- 
Michael Hutchinson
http://mjhutchinson.com