can you motivate yourself to finish something small? say something that will take you one week? if nothing comes to mind, can you say wake up at 6am everyday for a week? or walk 2 miles everyday for a week? or cook for yourself, as best you can, "interesting" dinners? just for a week.
after that week is over, maybe report back?
i would not make any life changing decisions just now.
In my experience, using CouchDB for prototyping is not fun. With SQL and (from what I gather) MongoDB, you can create ad-hoc queries as you go. Creating views in CouchDB requires thought and time -- usually lots of time -- to generate the views, unless you're working with a very small amount of data. Changing your mind is painful. You end up using weird hacks to get around rebuilding your views all the time.
Maybe I was doing it wrong, but it seems like if your app has more than a little data and you plan on changing your mind about how best to present it, you will experience discomfort.
I don't have any experience with MongoDB, but I am building an application right now using CouchDB and I've found it to be pretty easy to use -- definitely easier to prototype with vs a relational database + ORM framework.
CouchDB supports ad-hoc queries in the form of 'temporary views'. The downside (and I think a difference compared with MongoDB) is that temporary views can't be used in production since they are not indexed and thus are much slower than permanent views.
I'm developing my application in Python, which has great support for CouchDB in the form of CouchDB-Python (http://packages.python.org/CouchDB/) and CouchDBKit (http://couchdbkit.org/). Using CouchDBKit, it was pretty easy to set up CouchDB artifacts (map functions, reduce functions, design documents) into a nice file/folder hierarchy and write the simple Python glue code to deploy updates to CouchDB via a single shell command.
so far we're going with couch and haven't experienced this. the best part of course is that we can add items to documents on the fly whilst keeping the existing test data! this is major for us. we can go back to testing right away. with MySQL the changes were so major that it was better just dumping and recreating from scratch (we are using django) and this wasn't exactly fast. django has a project "south" that would help with this, but we're eventually deploying to oracle and cannot rely on it or have the time to extend it to properly work with oracle.
i guess i will have to try git to be sure, but i really don't see a difference here. usually if i'm going to try something drastic, i try it on a clone that i know i can throw away.
I often do it multiple times per minute. That wouldn't fly if each required a clone. :) (See another post I made in this thread for what I'm doing that involves so much history mutation.)
Yep – and I did it all, using those tools, for a couple of years. :) Now, when I go back to Mercurial (which I know better than Git, mind you), I get frustrated. Those tools are much more blunt than their Git equivalents.
so i tried it for a couple of days, and the speed was the thing that impressed me the most actually. the rest is not that dissimilar, but i didn't dislike it as much as i thought i would :) - our workflow assumes mq already so a git add is a qnew, or qref, a git diff --cache is a qdiff, a git diff is an hg diff ... so on. most commits i make are usually a qfinish, which is comparable to a git commit (no -a).
how do you manage patch queues in git? we need them because we are constantly backporting to different versions of our app. branches will mean n merges for n versions. stacked git? or is there a git native way to manage the same?
what about something like tortoisehg? gitk is pretty crude in comparison.
i assume one can glue a diff/merge tool like meld. is the experience similar when resolving conflicts?
Not really. In my subjective(+) opinion, Hg Queues are designed to work around the suboptimal design of branches in Hg.
Mucking about with a lot of small commits is a Good Habit and very useful when working from two different computers, but makes the Hg repository log terribly noisy. Eg. it invariably results in several "Oops, I forgot to add imgs.idx in the last changeset." or "This does not compile, but I committed it for backup purposes because I'm updating from Vista to Win7. Please check out the next changeset if you want to compile.". Git naturally supports squashing of commits to solve this, while Hg sans Queues does not. Git also allows you to kill off experimental branches that lead nowhere, while in Hg they live forever unless you make the "branch" in a queue ecosystem.
I will also pre-emptively counter a counter-argument which tend to always come up when I talk about this: "Swallow your pride; allow people to see your mistakes.": It's not about that; it's about keeping the repository history somewhat readable. Next week, someone on my team may have to look through all my changes for the code review, or in a few months when I'm on holiday someone might want to know what all the rework between versions 2.5.2 and 2.5.3 was so they can double-check that the release notes have been updated. Leaving these people to wade through piles of "Ooops"-es and half-commits is just sloppy and unprofessional.
(+) Disclaimer: I use Hg extensively at work, and Git extensively at home. I am frequently branching, merging, cloning, rebasing, squashing and generally mucking about in both, so I believe I know them fairly well. I prefer Git by several orders of magnitude.
we were working with hg for a long time and had a very elaborate workflow with queues. When we finally switched to git we missed our patch queues a lot. fast forward today, I don't even remember exactly why did we need them as much :).
Today we do all the same only better with git.
If I had to draw parallels I'd say hg's queues are used in a workflow like topic branches are used in git. its a way to 'edit history' that is basic in git but requires patch queue in hg (and don't really comes close in terms of functionality and easy of use). and just like in hg you can't change once you commit your patch, in git you can't (or rather shouldn't :) change once you merge into shared branch.
This is the sort of stuff I'm curious to hear. I have rudimentary experience with both Hg and Git. I have a project being managed in each and have found them roughly equivalent in basic use. I'd love to hear more details and stories from people who actually know both really well.
Actually, in general, I'd love to see more comparisons (not just VCS) that assume you understand the problem space and talk about nitty gritty details. I feel like I would learn more that way. Frequently, I find the same simplistic surface level arguments over and over, but rarely deep competitive analysis. I guess that kind of analysis is just harder and can only be done by people who have idiomatic expertise in both (and idiomatic experts are already rare).
so if you track project state with branches (for say versions) and you need to apply 'new feature' to all this n branches, does that mean n merges for your team? not for ours.
Cleaning up history to be readable, clean and represent the actual net change to the project instead of every dumb error I made is gold.
A properly managed history is a huge difference when it comes to dealing with code submissions. I tend to not take lists of changesets that include a bunch of "oops" because they take me a long time to figure out what the user actually did.
In some cases, I have really long lists with really small net changes but a whole lot of experimentation in the middle. I can't take those. They rewrite the entire history of giant chunks of the code to put this guy's name on them because he changed something and then changed it back and then committed half a change and then committed the second half, etc...
You say, "but this is fine, it's how he worked!" Then you have to track down a bug and see that it occurred in the middle of this "experimentation phase." That's when you realize that you don't care at all about the method of discovery, but really wish you could just hear what the discovery was in one changeset that is as small and clean and well-thought-out as possible.
I assume you're using histedit, rebase, and/or other tools and not just mq for your hg history munging needs? mq is a great tool, but it's not always the best one.
Also, you might find bookmarks useful if you don't use them.
Yes, I mean something else. :) When "--close-branch"-ing or merging back to "default" are closed and hidden in the branch list, but still present in the revision tree, and you get warnings if you try to create a new branch later with the same name. In Git they are just gone, as if they were never created. (Note that you have plenty of opportunity to restore them before garbage collection if you deleted one by accident.)
Branches don't really "disappear" in git, though. You're probably already aware of this, but for everyone not familiar with how git works:
Named branches in git are just moving references to commits. If you delete the pointer, the branch doesn't cease to exist, as it is present in the repository 'tree'. If you know the commit that was the head of the branch, you can easily create a new reference to it. The branch might eventually get garbage-collected if there is no other named ref that depends on it.
For example, if you merge "feature-foo" to "master" and then delete "feature-foo", the name is gone. However, the branch is still there (clearly visible in git-gui), and will not be garbage-collected because "master" depends on it.
The "problem" with hg in my opinion is that it attaches more meaning to the name of the branch than is necessary.
Of course, git also allows you to destroy commits, and destroying ones that you have shared with other repositories may lead to complaints from others developers. But that's a social issue; git will not (and never should) dictate what you do with your commits, it just tracks them.
first thing is to stop ruminating. even if your mind wants to. even if it feels like that is the best way out of this situation. so stop now. don't look for explanations, don't try to understand. that would make it worse. the answers are not in what we accomplish, or in what we think we need to do or be (great doctor vs. lowly coder) - all dangerous fabrications.
