Re: The One True Stage Re: Xcode - AN APPLE OPPORTUNITY!
Re: The One True Stage Re: Xcode - AN APPLE OPPORTUNITY!
- Subject: Re: The One True Stage Re: Xcode - AN APPLE OPPORTUNITY!
- From: Luther Baker <email@hidden>
- Date: Sun, 04 Mar 2012 00:51:09 -0600
It is not that difficult to confuse Xcode's SVN integration. I'm a heavy refactorer and I use a Git repo locally on top of a master SVN pull. Adding and then renaming or deleting files ... and then bouncing around from branch to branch in Git - and then working in Versions to diff, remove and delete files has confused my SVN plugin ... and at one point, from what I could tell, corrupted the underlying repository.
It seems to me that "mandatory source control integration" makes assumptions that simply don't need to be made. Skip the "right" / "wrong" part - I don't get why anyone even cared to do this? Maybe this is fine for some features ... but source control? Is source control integration so embedded in the IDE that it will fail to work without automatically managing my underlying repository?
When I think about the discussions that must have surrounded this decision I can't imagine how an experienced team could have decided to make the integration mandatory. Was it a lack of developer use cases or an actual bona-fide feeling that integrated, mandatory source control needed to be required in all cases?
I'm fine with making it *hard* to disable, but why eliminate it completely? An earlier Xcode4 release allowed you to delete the plugin ... but doing that now renders the application inoperable. If the plugin doesn't work *extremely well* with other tools it seems like there should be an option to disable it ... NO? I don't need half my day wasted trying to get rid of illegitimate warnings in Xcode or fixing a broken repo because adding, renaming and removing files confused the SVN plugin implementation. Xcode does not do SVN like Versions or Cornerstone or command line ... so why play that game, why make it *impossible* to turn off?
I've yet to find a rational answer to that question. It almost seems pretentious. And I don't know why we're even having this discussion. It's like trying to convince someone that line number and column position toggles are nice to have in an IDE.
Sure, I know it is one small corner of Xcode ... and I wonder if it was simply a naive, ill-considered decision ... but as it stands now, this little decision is *forcing* me to work in way that I KNOW isn't ideal for my situation. For now, I try to remember to open Organizer every time I start Xcode or open a new project and remove all the existing repos ... (and why do I have to repeat *this* every time?)
Just my $0.02 regarding the mandatory source control issue ...
-Luther
On Sat, Mar 3, 2012 at 11:03 PM, Roland King
<email@hidden> wrote:
On Mar 4, 2012, at 12:57 PM, Matt Neuburg wrote:
>
> On Mar 3, 2012, at 8:44 PM, Fritz Anderson wrote:
>
>> That's not the One True Model you have in mind,* but you do, in fact, "get to decide what gets ... to go into the next commit."
>>
>> * (And I could introduce you to someone whose One True Model derives from Subversion. Duke it out amongst yourselves until you come up with a UI that fits both.)
>>
>
> When I was using SVN, I ignored Xcode's version control features and used the command line. That's what I'd like to do with git as well, but Xcode is more proactive as regards git (perhaps because "add" means something very different in git than it does in SVN) so I must struggle against it. It's not fatal, but it is inconvenient, since, as Stefan said, I do end up quitting Xcode often to do a little git management. So, to sum up, I don't have in mind any One True Model. I would just like an option for no model at all. An *option*, mind you. I'm not saying what Xcode is doing is bad, I just think it would be even *better* if there were an *option* to turn it off. That seems a harmless and positive suggestion, and easily implemented - hardly a fit object of vitriol. m.
In what cases have you found it necessary to quit Xcode to run git from the command line? I've found it very tolerant of me making wholesale changes, including backing up to a previous revision with radically different files, on the command line and having Xcode just pick up and continue from where I end up. The only operation I've found flaky is merging back a branch which often results in all my targets being destroyed. I saw a comment about that on the developer forums too, so it's not just me.
Just interested in what situations Xcode falls over when git is messed about with behind the scenes, I've not found one.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (
email@hidden)
Help/Unsubscribe/Update your Subscription:
_______________________________________________
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