Re: Saving state of Schemes in svn repository?
Re: Saving state of Schemes in svn repository?
- Subject: Re: Saving state of Schemes in svn repository?
- From: Alexander von Below <email@hidden>
- Date: Tue, 02 Sep 2014 20:50:47 +0200
As we are moving quickly off topic, let me add my bit:
I kinda disagree. Things that use envVariables etc. should only be shared if these things are rarely, if ever, touched. We had the need for certain diagnostic schemes, and it was quite good that especially those could be shared across the team; it saved everybody from re-entering cryptic things in their setup.
You are right: Use with caution. And YMMV ;)
Alex
Am 02.09.2014 um 18:55 schrieb Quincey Morris <email@hidden>:
> On Sep 2, 2014, at 09:29 , Jens Alfke <email@hidden> wrote:
>
>> Changing properties of a scheme during development, like diagnostic features or environment variables, marks the scheme file as dirty, and then you either have to check in the changes (which is usually inappropriate, because not everyone wants to run with zombies enabled) or ignore the scheme file when committing.
>
> But, schemes can be shared or non-shared.
>
> Shared schemes are in ‘<project>/xcshareddata’, non-shared schemes are in a per-user folder inside ‘<project>/xcuserdata’. That gives you at least these choices:
>
> 1. If you want everyone using the repository to have the same setup of a scheme, make it shared (and commit the xcshareddata subfolder to the repository, of course).
>
> 2. If you want your own scheme setup to be backed up in the repository, make it non-shared (and commit the xcuserdata subfolder).
>
> 3. If you want to keep the scheme out of the repository, make it non-shared and git-ignore the xcuserdata subfolder.
>
> (You can apply this at a finer granularity, too, if you consider sub-sub-folders of those folders separately.)
>
> The workflow that this doesn’t cover (directly) is if you want to make *temporary* changes to a scheme that’s normally shared. In that case, though, it’s probably less confusing to create a non-shared copy of the scheme, that you delete later.
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden