Source code repositories - Page 1
Forum section: electronics / general

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: July 31, 2014, 03:46:31 pm
content: From that reading that thread about Arm tool chains. I was wondering about peoples attitudes to source control.Personally I use subversion with the tortoise interface, and have been happy with it for years.But so many people seem to use Git, I have tried it but I find it counter intuitive.In fact I have a lot of trouble doing anything with it, and just spend a lot of time trying to click areas of the screen to see if something happens, like what you had to do in very old video games.Obviously it is at another level being a distributed source control system, but I would have thought that you would need to be a fairly large project to really need a distributed SCS anyway.So is Git any use to a small player?What are it's advantages over SVN? The only advantage I can see is that a lot of projects are already using it, so for you to compile or change them it should be easier to work within Git.Any one use other forms of source control that they like?

author: zapta
author_rank: Super Contributor
timestamp: July 31, 2014, 03:52:49 pm
content: Quote from: HackedFridgeMagnet on July 31, 2014, 03:46:31 pmYes, it is counter intuitive but is the de facto standard and does the job. If you want to achieve X you can always search and find the magic command that does it.Quote from: HackedFridgeMagnet on July 31, 2014, 03:46:31 pmClick? Why not using the command line directly? For most jobs you need to know only a few commands: difftool, add, status, commit, push, pull.

author: jancumps
author_rank: Unknown
timestamp: July 31, 2014, 04:04:01 pm
content: I'm using git, blends in quite nice with my dev environment (Eclipse based).I don't find it counterintuitive, neither module nor command line.I'm used to work with version control systems as part of my job for umphteen years, mostly CVS.

author: free_electron
author_rank: Super Contributor
timestamp: July 31, 2014, 04:10:51 pm
content: what's wrong with simply creating a snapshot of the working directory and slapping a date and a serial number on it ? snapshot is made at every successfull compile time.i can roll back to any earlier compilation. i mark the ones that ran correctly by adding 'stable' to the folder name.zip it if you want to save diskspace. it's all ascii text so it compresses a lot.then again , i'm not a coder... what do i know. but it works fine for what i do. can be done using a simple batch file under dos. call it post compilation if compilation was success.

author: Prime73
author_rank: Regular Contributor
timestamp: July 31, 2014, 04:13:37 pm
content: Quote from: free_electron on July 31, 2014, 04:10:51 pmthat sounds like DIY source control with a lot of files, folders, etc. It's more efficient to use git or any other source control.

author: bwat
author_rank: Frequent Contributor
timestamp: July 31, 2014, 04:27:59 pm
content: Quote from: HackedFridgeMagnet on July 31, 2014, 03:46:31 pmClicking? You're one of those IDE types eh?Quote from: HackedFridgeMagnet on July 31, 2014, 03:46:31 pmI have several development machines, different target processors for testing and one of them is a small laptop that I use on the go. Git works well for me. If I'm moving from machine M1 to M2 then I I just "git push" on M1 then "git pull" on M2 and I'm good to go. I can go from one machine to the other in less than a minute.

author: IanB
author_rank: Super Contributor
timestamp: July 31, 2014, 04:36:30 pm
content: Quote from: HackedFridgeMagnet on July 31, 2014, 03:46:31 pmAs do others. Case in point:git man page generatorSubversion is getting a bit long in the tooth now, but it still works just as well as it always did. For personal projects if it does what you need I wouldn't see a reason to change.I think Git is not "good", it is just "popular". Not always the same thing.I've been using TFS for a while and I like it quite a lot. If you are working with Microsoft tools it would be a sensible choice.

author: zapta
author_rank: Super Contributor
timestamp: July 31, 2014, 04:41:57 pm
content: Quote from: free_electron on July 31, 2014, 04:10:51 pmHow do you cooperate with other people, merge changes, resolve conflicts, manage release branches, track changes, revert changes, etc?I worked once in a division of 700 engineers that worked just like that. Every Wednesday afternoon you dump your changes to a common repository. You want to be the last one so others don't step on yours. That was a very successful company BTW, eventually acquired for ~$10B.

author: bwat
author_rank: Frequent Contributor
timestamp: July 31, 2014, 04:45:35 pm
content: Quote from: free_electron on July 31, 2014, 04:10:51 pmRevision control tools aren't just for coders you know! If what you're doing works for you then nobody can really tell you that you're doing it wrong. Personally, I think your mental for doing it like that.

author: cyr
author_rank: Frequent Contributor
timestamp: July 31, 2014, 04:58:57 pm
content: I use TFS at work, and would not wish that on my worst enemy, but to each his own I guess.If subversion works for you, keep it.I use GIT for my personal work. The main advantage is the DVCS aspect, you can work on multiple machines (even offline) and always have the full revision history available, check in your work immediately, and then sync up later.It takes a little getting used to, but once you "get" the distributed aspect I don't find GIT particularly hard to use. It has many obscure features, but you shouldn't need to touch those in most cases.

author: jaxbird
author_rank: Frequent Contributor
timestamp: July 31, 2014, 05:02:10 pm
content: I wish there were much better support for TFS in many environments. IMO it's far superior to Git, SVN etc. when properly implemented. And actually it's much better than the SourceDepot used internally by most MS teams.Besides all the source control goodies, it's got completely configurable workflow features for iterations, task/feature/work item/bug tracking, triaging, reporting etc. etc.

author: rob77
author_rank: Super Contributor
timestamp: July 31, 2014, 05:13:31 pm
content: i moved from CVS to SVN approx 5-6 years ago and i'm staying with SVN. Git has no benefits for me and my projectsbasically everyone should use the version control suitable for the project and the team of coders (or individual coder in case of one-man show).

author: free_electron
author_rank: Super Contributor
timestamp: July 31, 2014, 05:36:25 pm
content: Quote from: zapta on July 31, 2014, 04:41:57 pmwhat other people ?i have the files i am responsible for. Nobody touches mine, i don't touch others. if a bug is found in my module i get notified, fix it and push the file out.Quotenothing ever gets deleted from my source. commented out. and documented. almost every line of code has a line of comment ( apart form the bleeding obvious of course). there's more comments than code.since i have snapshots from every successful build i can revert very quickly. every time a build is made the build number increments in the file. so if someone finds a bug in build 123 it gets fixed in 124. the offending code is commented out , marked with an explanation what is wrong , what build number had the bug, what build number fixes it and a timestamp and the corrected code is inserted below .there is one folder that holds the 'last known good build'on the build server i only have write permission to my files. i can include others as read-only.no need for complicated tools. a simple batchfile does the work.then again , i am not a coder dealing with thousands of files. i make the BSP and HAL and that's it. i have a testprogram for those. if the higher up coders find a problem i fix it and update the chain. They pull in the files they need in their build. works like a champ.

author: jaxbird
author_rank: Frequent Contributor
timestamp: July 31, 2014, 05:54:29 pm
content: Quote from: free_electron on July 31, 2014, 05:36:25 pmIt's fine as long as you work in a small environment and you can manage the changes etc. But a proper source control system can be a big advantage even with a small team, e.g. you can go back and see exactly what changes you made to fix a specific bug 6 months ago. Could be that the fix caused some regression not discovered until later, so when fixing the regression bug it's essential to know the details of the original bug fix.But the real strength of the best source control/build systems is when you work with multiple million lines of code produced/maintained by hundreds of people in various teams.

author: krivx
author_rank: Frequent Contributor
timestamp: July 31, 2014, 06:19:05 pm
content: Quote from: free_electron on July 31, 2014, 05:36:25 pmI'm sure it can work for a lot of cases, but it hardly does anything that an automated system doesn't, and you may miss out on features you get when you popular software.One disadvantage is you may be missing documentation of each version. A history of well-written commit messages should describe what was done between each commit, it can make solving problems much easier.How does a snapshot system work when someone leaves/retires and a new person has to maintain it? Read every snapshot?QuoteYikes... what happens when a bug is fixed, then crops up again later? Do you have to try every snapshot to find out when it was introduced, or start searching through the comments? I would be worried if I was using a system like this unless the software was simple enough that testing every feature was fast and trivial, like a short automation script or something.

author: SirNick
author_rank: Frequent Contributor
timestamp: July 31, 2014, 06:41:38 pm
content: My "version control system" is currently a laptop and desktop where I do my coding, and an rsync server where I keep the latest copy. (By "server" of course I mean a Linux box with a static IP that serves as my NAT firewall at home.)"make put" pushes changes from local box to server, and "make get" pulls them back. rsync doesn't manage conflicts so much as make the target look exactly like the source.It works well enough for synchronization purposes (and to prevent losing all my work due to a bad command or failed disk), but the time-machine aspect of a proper repo is making me consider SVN. There have been a few times where I went down a rabbit hole, realized it was a fool's quest, and wished I could undo the truckload of changes I made.

author: zapta
author_rank: Super Contributor
timestamp: July 31, 2014, 06:49:56 pm
content: Quote from: free_electron on July 31, 2014, 05:36:25 pmThis works only for small modules or for large brains. ;-)

author: magetoo
author_rank: Frequent Contributor
timestamp: July 31, 2014, 06:51:34 pm
content: Quote from: HackedFridgeMagnet on July 31, 2014, 03:46:31 pmNo, not if you already have something that works. The real benefits of Git come, or so I've been told, when you are working on huge projects and the sources are being worked on by dozens to hundreds of collaborators. (Git was created for managing the Linux kernel sources, so that's no coincidence.)If you want to dip your toe into distributed version control, you could look at Mercurial. It has areally good tutorialthat taught me lots about "why".

author: krivx
author_rank: Frequent Contributor
timestamp: July 31, 2014, 06:57:48 pm
content: Quote from: magetoo on July 31, 2014, 06:51:34 pmI would say a big benefit to git is that it integrates very well with many online services, there are a lot of online repository services that allow you to access your code anywhere. Mercurial has most of these kind of advantages as well (I think, not as familiar with it).

author: rob77
author_rank: Super Contributor
timestamp: July 31, 2014, 07:08:50 pm
content: Quote from: krivx on July 31, 2014, 06:57:48 pmthe benefit of the Git is that you can have a local clone and make commits to your local clone and then merge it to the "master copy".that's not possible with SVN for example - you always commit to the "master repository" (but you can have your branch there).

author: zapta
author_rank: Super Contributor
timestamp: July 31, 2014, 07:10:55 pm
content: Quote from: HackedFridgeMagnet on July 31, 2014, 03:46:31 pmI use it also for all of my single person hobby project. The repository is hosted by a free services (formerly google project hosting, not github) so I don't need to worry about backups and it is accessible from everywhere.(Github is more elegant, google code hosting has a better online diff tool)

author: magetoo
author_rank: Frequent Contributor
timestamp: July 31, 2014, 07:42:30 pm
content: Quote from: krivx on July 31, 2014, 06:57:48 pmGood point.Github definitely seems to be the place to be if you want to share code, and some sites/services will have some level of Github integration (especially web startups).Mercurial has a similar code sharing site I think, but I've never seen anyone use it. And then there are plugins that let you be cross-compatible and push code to Git, like hg-git, but I haven't really used that sort of thing either.

author: krivx
author_rank: Frequent Contributor
timestamp: July 31, 2014, 07:43:23 pm
content: Quote from: rob77 on July 31, 2014, 07:08:50 pmThat's a benefit of any distributed version control system. The post I was quoting was comparing Mercurial and Git, which can both do that.But yes, distributed systems can be much nicer to use than centralized systems like SVN.

author: free_electron
author_rank: Super Contributor
timestamp: July 31, 2014, 09:52:06 pm
content: Quote from: krivx on July 31, 2014, 06:19:05 pmlike i said , nothing ever gets deleted. only commented out and labeled. so it is easy to swap things in and out.anyway. my projects are always a one-man-show. i hand off my stuff and that's it. i only write BSP and HALs so everything is contained in one file most of the time.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: July 31, 2014, 11:28:18 pm
content: One thing that I find really useful is source control for Kicad. Especially libraries and modules but as all the saved files (that I know of) are text based I can use versioning and diff tools to understand what is going on.So it's not just source code it is:Source code.PCB files.Any office documents, invoices, quotes, test results, BOMs.Anything that is important and isn't too huge.So obviously not software-firmware binaries except for release builds.It also means I can back up my repository and thus all my important files easily to another disk. Though I would script this if I had too.I don't know how anyone works a desktop computer without some form of source control.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: July 31, 2014, 11:58:49 pm
content: QuoteYeah I forgot about Mercurial. I have also used VSS, and CVS but not TFS. The companies I have worked for didn't have the bucks to spring for TFS. $10000 from memory.I'm pretty sure I know why, just not 'why is it hard'?QuoteThis is why I need to use it, it is not so much dipping my toe in, I want to use, and peruse all this open source, so to do that I need to learn to use Git effectively.I can normally just dive into stuff and figure it out as i go along, but each time with Git I haven't got very far.I used XCode once and lost some work with the integrated Git. Not sure how. That's never happened with SVN.Then you see all these kiddies putting their stuff up on Git and think that I must be mentally deficient not to get it.Yes when I get time I will do the tutorials. Good things don't come easily.QuoteGuilty as charged.But really SVN works beautifully with the explorer integrated GUI. I'm not 100% sure of the need to cmd, shell everything.GitHub (my windows GUI app) looks beautiful but seems flawed, from the perspective if you have been using source control for years and can't just figure it out.

author: magetoo
author_rank: Frequent Contributor
timestamp: August 01, 2014, 12:20:45 am
content: Quote from: HackedFridgeMagnet on July 31, 2014, 11:58:49 pmGit has kind of become a common denominator for version control systems due to its popularity, so it's entirely possible that you can find a distributed VCS that works for you but speaks Git to others. Just to bring up another option.QuoteWell.. assuming they even get it. Knowing "how to do X" without actually understanding what's going on is pretty common.

author: miguelvp
author_rank: Super Contributor
timestamp: August 01, 2014, 12:24:33 am
content: At work we use Perforce, pricey but way more productive and integrates with a lot of tools, even GitSo far I have not seen anything better but I never used TFS.

author: Selectech
author_rank: Regular Contributor
timestamp: August 01, 2014, 12:36:19 am
content: Started using Mercuirial with the TortiseHg interface a while back. Easy to use and quite effective.Should have started using something like this earlier but having to set up separate servers seemed a pain in the but. Mercurial works with local and remote { private / public } and that works well for me.

author: apelly
author_rank: Unknown
timestamp: August 01, 2014, 12:44:19 am
content: I use git gui. Day-to day things are fine. New repositories require googling. The github docco has improved a lot recently.I figured I should just get over myself and get stuck in. So many devs use it, they can't all be wrong.Quote from: IanB on July 31, 2014, 04:36:30 pmAwesome! Haven't looked, but I'd bet someone has made one of those for awk too.

author: zapta
author_rank: Super Contributor
timestamp: August 01, 2014, 01:49:03 am
content: Quote from: HackedFridgeMagnet on July 31, 2014, 11:58:49 pmI tried to use a git UI (gitk), it looks nice but couldn't make sense of it, so just using the command line with a few basic commands I can memorize and shortcuts (e.g. dt for difftool). One positive point is that when you do 'git status' you also get hints how to do things like reverting a changed file.Personally I prefer the model of Perforce (which is what I have used professionally for more than 15 years). You define changelists, you assign changed files to changelists and you commit atomically any open changeless you want. Git may also do something similar with the 'stash' command but like anything else in git it's not obvious.

author: andyturk
author_rank: Frequent Contributor
timestamp: August 01, 2014, 02:11:17 am
content: Quote from: miguelvp on August 01, 2014, 12:24:33 amWow, people still use P4? Several years ago, I used perforce on my personal projects since a 2-user license was free. But that was then, and git seems to do everything that perforce did plus more cool stuff.Git has a heck of a learning curve though. Most of the people who use more than the basics are command-line heroes. There are a number of GUIs for git, but the complex operations don't seem to lend themselves to a clean UI. Personally, I do the basics (diffs and commits) within emacs and shell out to a command line for more complicated stuff. I used to use GitHub for publishing code and also for storing off-site "backups" of my repos. Now I have a local git server (separate from my working repos) and push stuff to BitBucket for backup. BitBucket is nice because you can have unlimited private repos."Git Flow" is a great way to manage software releases in a team environment, and I've even learned to appreciate submodules for integrating different codebases into a single project. The flip side is that I'm constantly hitting stackexchange to remember/relearn the syntax of obscure functions.Git is good. Go with git.

author: IanB
author_rank: Super Contributor
timestamp: August 01, 2014, 02:17:13 am
content: Quote from: zapta on August 01, 2014, 01:49:03 amThat's rather how it works with TFS, except changelists are called changesets. You can assign one or more changes to a changeset, one or more changesets to a task, one or more tasks to a work item (bug or feature), and one or more work items to a requirement.If anyone's interested to give it a try, TFS Express is free for personal or small team use. You can easily use it alongside other code development tools or IDEs if you want.

author: miguelvp
author_rank: Super Contributor
timestamp: August 01, 2014, 02:40:19 am
content: Quote from: andyturk on August 01, 2014, 02:11:17 amP4 has evolved quite a bit, lookup perforce streams, but I guess it all depends on what features you use. If you are happy with the basic functionality then might as well use Visual Source Safe 6.0d (of course I kid, and don't use a 6.0 client on a 6.0d database unless you want to loose the whole depot).But when it has to be accessed by hundreds of users with dozens of changelists each it's just a breeze in Perforce without having to study all of the commands, it also integrates with Jira so you can track bug lists.It also integrates nicely with VS and Eclipse, and there is even a plug in for Notepad++. Also you can use Beyond Compare instead of the default comparison utility and that makes code reviews easy to do. You can shelve changes that are not committed as well if you need to work on something else, Code resolution is fast to do when you sync to head, all those operations are just clicks and quick to execute. You can also open a project from Perforce and it grabs everything for you. It integrates well with electric commander for build automation and you can see who broke the build and go to his/her desk and stand behind them until the fix the build. List goes on. I never tried the Git Fusion features but that might make using Git a breeze as well using Perforce.Edit: scratch Git Fusion, that only provides Git access to Perforce depots.

author: zapta
author_rank: Super Contributor
timestamp: August 01, 2014, 02:41:48 am
content: Quote from: andyturk on August 01, 2014, 02:11:17 amThis is still the casehttp://www.perforce.com/company/newsletter/2012/02/perforce-now-free-20-usersPerforce is the best version control system I have used. Intuitive, scaleable, and require virtually no administration. Only problem it is not supported by the cloud repository services like github.

author: andyturk
author_rank: Frequent Contributor
timestamp: August 01, 2014, 02:57:58 am
content: Quote from: zapta on August 01, 2014, 02:41:48 amI'm sure it still has compelling features for enterprises. But for open source projects (with no budget) and smaller teams, git is the new standard.What does a Perforce seat cost these days? I remember it being $600/user.

author: zapta
author_rank: Super Contributor
timestamp: August 01, 2014, 03:01:12 am
content: Quote from: andyturk on August 01, 2014, 02:57:58 amIt's about the same, for a perpetual licensehttp://www.perforce.com/purchase/pricing-licensing

author: andyturk
author_rank: Frequent Contributor
timestamp: August 01, 2014, 03:14:26 am
content: Quote from: zapta on August 01, 2014, 03:01:12 am"Standard Support is $160 per user. New Perforce customers are required to purchase a license with technical support for their first 12 months."Yikes! Looks like Perforce is following in Altium's business model footsteps.

author: miguelvp
author_rank: Super Contributor
timestamp: August 01, 2014, 03:23:14 am
content: Quote from: andyturk on August 01, 2014, 03:14:26 amThat's why you have your perforce specialists, not every user needs to deal with the depot issues/configurations/etc.

author: vvanders
author_rank: Regular Contributor
timestamp: August 01, 2014, 03:24:41 am
content: Quote from: zapta on August 01, 2014, 02:41:48 am2nd'ing P4, it's the only thing that handles large files in a sane way as well. Once you crack 1GB repos git starts to fall over quickly(which is why google uses repo to manage Android, but that's not really source control...).

author: vvanders
author_rank: Regular Contributor
timestamp: August 01, 2014, 04:25:40 am
content: Think? Haha, I know.We've got multiple 8+ GB repos that regularly fail to sync with obscure error messages. A checkout of them takes well over an hour.P4 will pull down a 30GB repo without breaking a sweat and back when I was in games would do a 100GB art sync without issue. The other problem is that with large repos you get all the local history. so what might be 1GB working set ends up being an 8GB sync on every client.There's also the intrinsic problem with DCVS around unmergeable binary files that there is no central locking mechanism but that's a discussion for a different time.As they say, use the right tool for the job. Git has many advantages but it's not the end-all be-all.

author: Dago
author_rank: Frequent Contributor
timestamp: August 01, 2014, 04:33:42 am
content: I personally use Git for my projects but rarely need any complicated features other than stash or something.At work we use SVN and people seem to dislike it (not "hate it") and most of our developers seem to be using git-svn so they can use git locally.

author: zapta
author_rank: Super Contributor
timestamp: August 01, 2014, 05:41:34 am
content: Quote from: andyturk on August 01, 2014, 03:14:26 amThis is for an annual license. Scroll down the page for perpetual license.

author: zapta
author_rank: Super Contributor
timestamp: August 01, 2014, 05:47:04 am
content: Quote from: miguelvp on August 01, 2014, 03:23:14 amFrom my experience, perforce require virtually no administration. Years ago I worked for a startup, we looked for a version control system and settled on perforce. Since I did the installation I because the de facto 'administrator' but there was nothing to do. A few years after I left that company I met with one of the guys that was still there, when I asked him who is administrates the perforce server he said 'no one'. They even didn't notice that they don't have a perforce administrator, things just kept working.

author: miguelvp
author_rank: Super Contributor
timestamp: August 01, 2014, 06:02:27 am
content: I worked for startups and that was the case as well, pretty much we all wear a lot of hats, even our server side programmer took care of setting up the phone system and did the server maintenance as well.But in my current workplace, it's all by the book, and we hook perforce to everything so we need at least one guy that owns the technical side and the IT dept takes care of the server side of things. On the startups we didn't have IT guys, just programmers doing support for the rest.Anyway, I did download the 20 user thing for home use, since I know the tool might as well. Now I wonder if I can get Quartus II to use source control automatically and if they have places I can put scripts for that. Not a biggie because I can always checkout in windows explorer, so at least I could do a save as and check out the file from the dialog box

author: Bored@Work
author_rank: Super Contributor
timestamp: August 01, 2014, 06:04:13 am
content: Quote from: andyturk on August 01, 2014, 02:11:17 amNo. I am a command line user (makes it much simpler to automate complex procedures). But I i considere git hyped shit. No substance. I use it if I can't avoid it, but that's all.Git solves problems I don't have and creates problems I don't want to have.Git even exceeds the suckage factor of Clearcase. Clearcase has at least some ideas that sound good and usable on paper - until you realize you need a team of full-time Clearcase admins to not only get it going but keep it going.I'd rather use crusty, sucking CVS, RCS or even stone age SCCS, then voluntarily introduce git to my projects. That is how useless I find it.Especially the own local repository thing in git creates problems when you work in a team. It promotes a behavior I seek to eradicate. The least thing I want to have is that a lone hero coder isolates himself and works on the code in isolation over a long time. This typically escalates when our lone hero decides to finally make his masterpiece known to the world by pushing his junk out to the main repository. For increased impact this "code vomit" happens on a Friday afternoon. For maximum impact our lone hero then disappears on a two weeks vacation in Vegas. And leaves it to his (soon ex) colleagues to clean up his mess. Thank you very much...Here is how I want and enforce it: A central repository to be used by all, continuously. Otherwise you are in trouble. A least daily integration and checkins by each developer, except on Fridays. Many small integrations and checkins over the course of the day encouraged, whenever a change was done, integrated and (unit) tested. Learn how to structure and execute your work and code changes in small increments, dammit.Absolutely no code vomits. Absolutely no hidden, behind the back, secret, hero, special version, holding back, private repositories. One needs to try out something? He gets a branch for a week or two, not longer. At the end it is decided if it is good. If yes he himself has to merge it into the latest main. Yes, merging is annoying hard work, and if he was clever he continuously updated the branch code with the main code while working on the branch. Then the branch gets locked, back to the main.

author: bwat
author_rank: Frequent Contributor
timestamp: August 01, 2014, 06:38:36 am
content: Quote from: Bored@Work on August 01, 2014, 06:04:13 am?Quote from: Bored@Work on August 01, 2014, 06:04:13 amYou don't simplify the problem to suit your frames of reference. Your frames of reference need to be expanded to suit the problem. Your diktat is not a solution.

author: zapta
author_rank: Super Contributor
timestamp: August 01, 2014, 06:45:00 am
content: Quote from: Bored@Work on August 01, 2014, 06:04:13 amWe have a different approach. Nobody cares how you create your p4 changelists or how long you work on them as long as they are correct and clean. When you want to submit a changelist you push it to an awesome collaborative code review system and ask one of your buddies to review it. Once the changelist satisfies the reviewer you can submit it. It's up to you what tools to use to craft your chagnelists. Some people use a private git instances to manage their work and fancy IDE's to edit, others work directly against P4 using vim, it's nobody's business how you generate your changelists.

author: ivaylo
author_rank: Frequent Contributor
timestamp: August 01, 2014, 06:54:57 am
content: Source control for a 100+ developers, multiple simultaneous releases and live fixes project is one thing. Working on your own or coding with your buddy in the same room another. Through the years had to deal with Source Safe, PVCS, CVS, RCS, SCCS, SVN, Perforce, Clear Case and all of them are PITA in one way or another (but again, those were built to solve problems most people don't have). Git is no worse or better than most. Would't call it a fad but I do see a bit of a cult around it. For pulling from or publishing to public repositories (no matter svn, git, mercurial, whatever...) as an individual contributor you need to learn 2-3 commands (the GUIs make things look more complicated than they actually are). For taking care of your own files all of this doesn't really matter, pick something free for which you don't have to run a server.

author: rob77
author_rank: Super Contributor
timestamp: August 01, 2014, 07:25:10 am
content: Quote from: Bored@Work on August 01, 2014, 06:04:13 amand exactly that's the reason why i'm using SVNif a colleague makes a new feature in isolation the SVN doesn't allow him to commit till he updates his local copy and he solves all the conflicts.and actually it doesn't have to be a "local hero" - it might happen that someone makes "a temporary hack" for his local testing and forgets to revert the hack before commit.

author: westfw
author_rank: Super Contributor
timestamp: August 01, 2014, 08:57:21 am
content: QuoteAh; another Clearcase PTSD patient!I've used RCS, CVS, and Clearcase "professionally." RCS is swell for "one person working on some subset of the files at a time." It's what I used for local, personal projects that I think deserve version control. CVS seems to come into play when multiple people are working on the same files at the same time and you need "merging" capability. Clearcase ... causes PTSD. Maybe it's useful for really massive projects with lots of engineers distributed across lots of machines. As long as you're willing to have that administrative group, and put up with the performance degradation. Sigh.I've used Mecurial, SVN, and git for code I share on the net, without really understanding what they do for me. Most of those projects involve either single developers (me) or weighty "discussion" before any patches are accepted, so a lot of what are apparently supposed to be their big selling points seem wasted or irrelevant. (and I use them all about the same, using a pretty minimal subset up the commands. More of a source "sharing" tool than a "control" tool.) And I'm rather annoyed that they seem to conjure up new terminology where I didn't think any was needed.I like that RCS keeps files write-protected unless you specifically decide that you want to edit them. (I've got an EMACS macro that will "check out" the current buffer, whether RCS, CVS, or Clearcase is in use.)

author: andyturk
author_rank: Frequent Contributor
timestamp: August 01, 2014, 11:16:29 am
content: Quote from: Bored@Work on August 01, 2014, 06:04:13 amGo easy on the coffee, OK? Wow.You don't need any source code control system at all to implement your (briskly unique) ideas... Just have one keyboard that's shared by all your programmers.