source code check ins
-
Branches are easy to create, very easy... the problem is Merging which almost all the SVN / CVS lacks (It's the design flaw). and it requires lot of manual work. :)
I use svn... Once you get the hang of doing merges... Not very hard at all...
-
looks like bug to me, if you are on the post above and press ctrl + ->, they are messed up but if you are on the post below and press ctrl + <-, then looks ok.
-
We do have other methods of backup in case a machine crashes. But you have a point. It's probably a lot easier to recover from some kind of failure if you use those features in your source control instead.
Plus if you use multiple machines, it is way easier and faster to move your source around.... Since once you've done the initial checheckout, you just have to update from the repository (get changes instead of whole thing).
-
When using centralized SCS (TFS, SourceSafe, SVN) I normally checkin after a unit of work has been completed. This is basically a small feature or a fix. When using distributed SCS (GIT and mercurial), I check in as often as I can sometimes even after modification of a single file. Of course, I push it to the centralized build server only after a unit has been completed.
If you're using TFS, you can shelve your changes.
-
looks like bug to me, if you are on the post above and press ctrl + ->, they are messed up but if you are on the post below and press ctrl + <-, then looks ok.
Define "messed up" and "ok". I know that IE has a bug where OL items will all get a value of 0 and interacting with the page a bit will restore the numbers to their correct values.
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
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.
Paul Watt wrote:
Rational Unified Change Management
I think I need to rename the app I'm working on to "Free Unified Change Keeper". :cool:
-
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
Jim Crafton wrote:
the project has people checking in whenever they save a file.
That seems wrong on so many fronts. IMHO, a checkin should reflect a bug fix or a (partial or complete) feature implementation. The important thing is, a checkin should be revertable without breaking the build or run-time functionality. We use TFS's shelveset feature all the time, allowing us to preserve (and share for code-review) partially completed pieces of work without fear of losing data or corrupting the codebase. Looks like some (gently proffered) developer education is appropriate. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Jim Crafton wrote:
the project has people checking in whenever they save a file.
That seems wrong on so many fronts. IMHO, a checkin should reflect a bug fix or a (partial or complete) feature implementation. The important thing is, a checkin should be revertable without breaking the build or run-time functionality. We use TFS's shelveset feature all the time, allowing us to preserve (and share for code-review) partially completed pieces of work without fear of losing data or corrupting the codebase. Looks like some (gently proffered) developer education is appropriate. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Yes, that's what my friend thought as well. Unfortunately he's not in a position to do anything about it, just make the best of the situation and move on.
¡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
Jim Crafton wrote:
How often do you check in?
It depends where. What you describe looks like two problems in one. First, everybody seems to be working in the same branch. Second, people are using check ins as save operations ( unless there are 50,000 programmers in the company, in which case 100 changes / hour is not uncommon). The repository architecture plays a very important role in the check-in process. If the integrator did not think out his repository structure well ( numbers of branches, dependencies, ...), you can end-up needing ten times more time to achieve the same task; this is something that is frequently forgotten when a project starts, because at that point of time, there is little code and little dependencies. And once it grows, it is to complicated too re-engineer, and that's how you end up in the situation you've described. The *good* frequency of check-in depends on a lot of parameters. When you are working alone on a branch on some not so important change with a good back-up system (SecondCopy...), you don't check in as often as if you work on an important big fix on the main trunk without back-up at all. Breaking the build is usually never a good idea, since others could use your broken code as a base, and the nightly build and unit testing would all fail. But if you are alone in your branch and want to save your work before going home, and it does not compile, why not do it ? Configuration management is almost never taught in school, although being a very basic knowledge of project management and software development... :^)
-
I use svn... Once you get the hang of doing merges... Not very hard at all...
Albert Holguin wrote:
Not very hard at all...
Yes, but it is waste of time. If you have to decide what needs to be there, and what is old, then why you need the source control, you can use a shared network location. right ? and this gets very time consuming if you are working on a large project with many teams, and some guys are offshore. instead DVCS does this automagically. you can even check-in your code without any network/internet connection.
-
Define "messed up" and "ok". I know that IE has a bug where OL items will all get a value of 0 and interacting with the page a bit will restore the numbers to their correct values.
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
ok, messed up means your int.min values, and ok means 0. :) and now I know that you mean reverse.
-
Albert Holguin wrote:
Not very hard at all...
Yes, but it is waste of time. If you have to decide what needs to be there, and what is old, then why you need the source control, you can use a shared network location. right ? and this gets very time consuming if you are working on a large project with many teams, and some guys are offshore. instead DVCS does this automagically. you can even check-in your code without any network/internet connection.
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 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
-
Oooh - the days of ClearCase (I think this is what this used to be called). I remember all that now! Yeah it was a bit over blown, but it did have a lot of nice features once it was all set up correctly. But I think all the developers bitched about the amount of time it took to get used to it. It was also a nearly full time job to babysit the server to keep it up and running and happy :)
¡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
Yep ClearCase. Thankfully, we have people, which that is all they do, manage the servers and the different repositories.
-
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
If im going to be seriously changing/ adding to the project ill have my own branch and check in when working or as a minimum building. If i am making minor fixes ill just do it then check in once working. If you break the trunk from building your a bad person on the inside :mad:
-
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.
