• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Why does SCM have to be so ....... hard?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why does SCM have to be so ....... hard?


  • Subject: Re: Why does SCM have to be so ....... hard?
  • From: Christoffer Lerno <email@hidden>
  • Date: Mon, 20 Sep 2004 10:03:20 +0200

Hi Daryle,

1. Creating a new file automatically adds it to my repository
2. Editing a file automatically checks it out.

I guess you really mean "marks it for editing". (A file has to be checked out first to be available for any kind of local work!) This is really applicable only for SCM systems that use exclusive locks. Other systems (like CVS) assume that files are always editable, and worry about conflicts (from multiple editors) only upon check-in.

Yes, sorry about that. I meant mark for editing.

3. Saving a file commits it to the repository

This would be really annoying for people (like me) who save a file many times before finishing a complete change, especially if commit comments are required.

This is true. Actually it turns out I had a too naive view of what the typical SCM could be used for.


Obviously the standard use is to work with a few files until the change is finished (and it builds correctly) and then check it into the repository.

For a local project then, you could achieve the same result by duplicating the whole source directory once in a while. Of course, the more collaborators there are the more essential SCM becomes.

So what did I have in mind? Well, like I wrote elsewhere, what I had in mind was more of something like a complete annotated _local_ history over the source-files of the project and I erronously believed SCM included such things.

The advantages ought to be pretty apparent. For example it would be easier to experiment with different solutions, because reverting to an earlier, working, version would be trivial; there would be a local back-up of all the files one is playing with in case of an accidental delete (I accidentally erased all the files belonging to a project and my latest backup was half a month earlier, but because intelliJ IDEA had kept a copy of all of my files in it's history, I could get everything back) and so on.

And such an annotated history should obviously need to work something like I described.

I'm sorry I didn't make sense the first time around.


/C

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: Bindings: how to deal with canRemove ?
  • Next by Date: NSData questions (including Altivec)
  • Previous by thread: Re: Why does SCM have to be so ....... hard?
  • Next by thread: Re: Rotations
  • Index(es):
    • Date
    • Thread