source code check ins
-
Rutvik Dave wrote:
If you have to decide what needs to be there, and what is old
??? ...that statement doesn't make sense to me... but anyway, we had our dev/engineering team split in the east coast and west coast and it worked out fine. There's positives and negatives to every system.
I was pointing out that how you have to manually resolved the conflicts (many times) at the time of merging. also, I am not saying it is not going to work, there are hell lot of people who are using SVN. I am saying that, it is not efficient and there are more efficient systems available. :)
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
Sounds like the people who put together the source control system have definitely checked out. Marc
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
The absolute minimum should be 'it doesn't break the build' (though I have accidentally breached this sometimes by e.g. forgetting to save a project file before committing or missing out adding a file to the repository). If you need to check in something which is partially complete and you know it is broken, you should make a branch (or use your local repository, if using GIT); unless it's a huge task (over a week), I have faith in my computer's hard drive and I won't check in until I have at least a subset of functionality that doesn't break anything. It's a good practice to only check in when tests pass (both unit tests and, if it's front end, usability tests). Depending on the project structure, sometimes that isn't possible.
-
We only check in code when it's been tested and is ready to move to the production server.
Kschuler wrote:
We only check in code when it's been tested and is ready to move to the production server.
:doh:
---Guy H ;-)---
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
Coffee-flavored? Hazelnut? I told you I'm no good at word games. Sure, I've seen this all the time in a small group. It's the result of people not building and testing before checking in. I used to check in once every day if I could be sure my code would build and work. If not, then when it got stable. Now I'm the only one working on a project so I only check in when the code is ready for release.
-
I usually check in a few times per day. Reasons I check in: I reached a major milestone, I am adding something to a project (I add it and check it in before it's implemented to avoid having to merge project conflicts), I finished what I was doing (even if it was a quick fix for a comment), or it's the end of the day. I will avoid checkins if:
-2147483648. The code doesn't compile.
-2147483647. The code will break something that is on production.Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
I do exactly that, except for number 2. Number 2 is not a possibility because checking in code does not affect production, only development. Releases to production are produced as branches on the repository, marking as a milestone that needs to be thoroughly tested and can be easily identified for directed bug fixes while a new version is not ready for release.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
We only check in code when it's been tested and is ready to move to the production server.
Then how do you use Visual Studio Team System? No code sharing between developers when in development?
Regards, Jwalant Natvarlal Soneji
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
In our team we encourage checking in as often as possible. We check in when we have a something that works - even if only partially and with no visible deliverable. No code is checked in without a code review. We use Jetbrain's TeamCity with pre-tested commits and unit tests, so it is not possible to check in code that breaks the build or the tests (integration tests excluded). We have found that frequent check-ins encourages building code up in incremental blocks and unit tests. It also makes it much easier to refactor your own changes without affecting code that you are happy with (read: just recently checked in). Code reviews become less time-consuming when few files are checked more often (20+ file changes is also a mental strain when reviewing code).
-
We have used IBM Rational Unified Change Management, which is very overwhelming at first, and a bit heavy on process. In a large organization, I think it's the only way to go. Each developer gets their own "view" of the source. I can check-out and check-in my source all I want in my view. After I am done developing, testing I "deliver" to the integration stream that everyone on my team is working on for the current project. Before I finalize the delivery, I can actually build from the integration stream to verify that I didn't break the build. If anyone tries to update their source during that period, they will get the code at the point before I deliver. If I find I have made a mistake, I can easily back-out the check-in, and try again once I have resolved the issue. Finally, the changes from the integration stream can be delivered up the chain to the base stream.
We use UCM as well, but we use a lighter model. (25 developer team, all local) We use the project integration stream as our "trunk". We use snapshot views (local file copies) against the "trunk" which provides sufficient isolation without the developer having to support yet another view of the code. We create monthly stability branches that are development streams beneath the "trunk" stream. The monthly stability stream allows bug fix work to be performed, developers get "free" merging back to the trunk via delivery operattions (merge). For delivery from the stability streams, developers create a second snapshot view of the trunk in which they perform NO checkouts/checkins. It is only used for delivery. This allows them to have checkouts in their main "trunk" view. (CC does not allow delivery to a view with checkouts). Roughly once a year or if we make some major development shift, we rebranch/copy the old trunk and create a new "trunk". This prevents the branch on branch on branch, etc. from building up too deep. We map each ClearCase Component to an IDE project, and use ClearCase Composite Components to bundle a group of projects into a Solution/Workspace. Barring infrequent major upgrades, we spend less than a man week/year on ClearCase maintenance. My brother works at a shop where they do NOT use UCM. They have 3 ClearCase admins for about 40-50 developers and a bunch of custom triggers and idiotic rules that slow things down.
-
Then how do you use Visual Studio Team System? No code sharing between developers when in development?
Regards, Jwalant Natvarlal Soneji
Correct. We are a small enough company with only a dozen or so programmers so usually only one person needs to work on a certain DLL class or web page at a time. We manually merge code together in the rare instances when two people require the same code. It just never seemed worth the time to stop and learn exactly how to use our source control to it's full extent.
-
Then how do you use Visual Studio Team System? No code sharing between developers when in development?
Regards, Jwalant Natvarlal Soneji
Assuming that you're talking about TFS you can "shelf" the code either daily or before you go on vacation. Shelving doesn't mix it in to the code base the way a check-in would, but you have a backup and if someone else needs to take over (you're hit by a truck/they're done with their stuff/etc.) then they can. I'm still learning TFS and am supposed to teach it to my team, so pardon if the words are a little off. HTH, -Chris C.
-
I have a "friend", whose working on a project implemented in a coffee flavored language. My friend has observed that the project has an extreme rate of checkins - update once, and 10-15 minnutes later there will frequently be 20 or 30 more updates to grab. Making my friend think that the project has people checking in whenever they save a file. A side effect seems to be that you can update, have a broken build, report it as broken, only to have the "fix" mysteriously checked in while you're emailing the problem in. Another update, and the build is "fixed". Has anyone else heard of this? How often do you check in?
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
My friend suggested to create a batch script which works as a shortcut to fetch latest "required" files from VSTS when executed. This helps in disregarding number of check-ins.
Regards, Jwalant Natvarlal Soneji