|
For the Mercurial equivalent of GitHub there's BitBucket. In addition to unlimited public repos, you get one private repo for free, and you get bug trackers for each repo. You can also configure it to change tickets from commit messages, and it can integrate with CIA, Lighthouse, Basecamp, and other services. And I believe with the pay plans you can use your own domain name with the service.
|
#
¿
Apr 11, 2009 18:04
|
|
|
|
| # ¿ Apr 28, 2024 18:06 |
|
|
Janin posted:It's got a stable API, so instead of having to write extensions by parsing output from other commands, you just import bzrlib. Mercurial does all of this as well. My first DVCS was darcs. It was great, very intuitive, especially being patch-based. I did run into ridiculous performance issues, and corrupted my repository on a couple of occasions. I don't remember exactly how I happened upon Mercurial, but I've been happy since switching. I tried out Bazaar a couple of times around that time period. I kept seeing it being touted as the most user friendly DVCS out there, but honestly I didn't find it any more friendly that Mercurial. The lack of a built-in repository web application was a killer too - nothing compares to "hg serve". The constant format changing was also disconcerting, and the performance was lacking at the time. I remember reading that sometime in the past Mercurial and Bazaar were poised to merge, but Canonical shot down the whole idea. I think they're going to find themselves slipping into obscurity very quickly if they don't catch up to Git and Mercurial soon. But I do have to say, I just can't imagine going back to Subversion ever again. I know it's ubiquitous and I know many people say it works perfectly fine. But after having the ability to do all my versioning locally, I just can't go back to that. And I've found that if you try to do concurrent development on the same branch with other people, it gets very ugly. Allie fucked around with this message at 05:50 on Apr 17, 2009 |
|
#
¿
Apr 17, 2009 05:48
|
|
|
Ferg posted:How will you know when a fork/merge occurred though and when? If a changeset has more than one child, new branches have been created. If a changeset has more than one parent, a merge has occurred. http://eagain.net/articles/git-for-computer-scientists/ http://git.kernel.org/?p=git/git.git;a=blob;f=graph.c;h=6746d422a98ed010489d4ce74b26a8a4600b183e;hb=HEAD This might be easier to read than graph.c, and Mercurial's history model is essentially the same as Git's: http://selenic.com/repo/hg/file/17da88da1abd/hgext/graphlog.py
|
|
#
¿
Oct 16, 2009 01:05
|
|
|
stray posted:Thanks, Janin. I decided on Git, since it seems to be a pretty smart system. Git has built-in facilities for tagging and branching, so no, definitely do not do that.
|
|
#
¿
Mar 4, 2010 23:01
|
|
|
Sizzlechest posted:He's looking to set up a repository at work. He didn't explicitly say it, but I'm going to go out on a limb and guess the following are true: These are all bullshit reasons. 1. You can do fine-grained access control in a distributed system: your central repo server would enforce these rules. 2. You don't lose control over the source code just because you're using a distributed system any more than with a centralized system. 3. Even if you have a great network, having most commands run instantly is still a plus. It's even more useful if you're telecommuting or you have multiple locations. 4. Branching doesn't just mean making a "flavor" of a codebase: you branch when you want to implement a large feature without loving up the current main code base, you branch when you need to maintain old maintenance branches. 5. If you're branching in svn, you're gonna have to do merges no matter what. With Git or Mercurial it's most likely going to be a lot easier. They're just better at branching. If all your devs are using one svn repo, well, then you're all gonna be doing a tons of mini-merges with each svn up, which is annoying as gently caress. The only real reason not to use Git or Mercurial is if you need to version large binaries. Where I work we migrated from Subversion to Mercurial, and it's been great.
|
|
#
¿
Mar 11, 2010 18:29
|
|
|
Lysidas posted:I'd argue that Git is superior in every way (and easier to use), but I'll admit that it isn't yet suitable for all Windows developers. Just out of curiosity, what makes Git easier to use than Mercurial for you? I use both, but I find Mercurial a lot simpler UI-wise.
|
|
#
¿
Mar 11, 2010 18:52
|
|
|
Lysidas posted:I'm having a harder time elaborating on this than I expected, which means that Mercurial has improved quite a bit since I last used it. Note that I said "easier", not "simpler", though Yeah, hg doesn't have an index. When I want to commit a subset of files, I just list them in my hg commit command. If I need to commit specific lines, I use hg record. I guess it's a matter of opinion which system is better. Mercurial does ship with a rebase command, but it takes the stance that editing history should be reserved for people who know what they're doing, so the command isn't enabled by default. You can amend commits by using mq (a patch management tool), but that's definitely more complicated than git commit --amend. You can also do something like filter-branch by using hg's convert extension.
|
|
#
¿
Mar 11, 2010 19:49
|
|
|
Vanadium posted:What does branching/merging look like in hg compared to git? I am tracking a hg repository in git using hg-git and slightly confused! I think merging is essentially the same in both systems, but branching is significantly different. The usual way to do feature branches in Mercurial is by cloning a separate repository on disk. This uses hard links, so it doesn't eat up a huge amount of space. Long-lived branches (e.g. stable vs. main) are usually done with something called named branches, where Mercurial records branch names as part of the history. These usually live inside a single repository. Git takes a different approach: branch names aren't an immutable part of the history, they're just moving markers, and multiple branches usually live inside the same repository. Remote changes often go in their own branches, which isn't the case in Mercurial. hg-git uses Mercurial's bookmarks extension to do Git branches. Bookmarks are mutable changeset markers, just like Git's branches. Bookmarks can't be pushed and pulled yet, however.
|
|
#
¿
Mar 11, 2010 20:01
|
|
|
Mercurial's tags are pointers, but they're part of the history, so they get committed. If you're doing hg clone -r tagname to "check out" a tag, you won't get the revision where the tag was added, since that came after (it points back). A better approach is to do hg clone -u tagname, which grabs the entire history and then updates to tagname. The reason they're part of the history is so they can be merged and conflicts dealt with. That's also why they live inside the repository, otherwise they wouldn't be versioned. Also, you don't edit .hgtags directly; there are commands for adding, removing, and overwriting tags. I've heard people go both ways on local branching and separate clones. I think the stance of mpm (the creator of hg) is that it's more useful to have separate directories, so you can actually edit the two branches at the same time, run their tests separately, etc. Bookmarks are a recent invention, and Mercurial's development practices favor a slow, deliberate approach to things, so they started with just the local implementation. The pushable implementation should come in 1.6. If you're curious, here are a couple of good articles on Mercurial vs. Git branching: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2010/02/mercurial-workflows-branch-as-needed/ Allie fucked around with this message at 20:26 on Mar 11, 2010 |
|
#
¿
Mar 11, 2010 20:24
|
|
|
Or with hg 1.4 or newer:code:code:
|
|
#
¿
Apr 10, 2010 07:50
|
|
|
If you use shares with Windows machines, make sure you upgrade to at least 1.6.3 (1.6.4 is the latest). They just fixed a longstanding hard link corruption issue due to a Windows API being broken and giving bad information about hard links on network drives. You can also run hgweb under IIS, but that requires more configuration up front.
|
|
#
¿
Oct 6, 2010 05:55
|
|
|
|
| # ¿ Apr 28, 2024 18:06 |
|
|
uXs posted:Mercurial does track renames, but you need to explicitly tell it about them. Basically this boils down to using "hg mv" or "hg addremove" when you want to record renames. Future versions of Mercurial will probably take a hybrid approach and do both explicit recording and Git-style rename detection. The whole bit about Mercurial not tracking renames is some bullshit Mark Shuttleworth made up in a blog post years ago. Mercurial has always tracked renames.
|
|
#
¿
Oct 12, 2010 21:49
|
|