|
We use SourceSafe (but we're looking to switch.) I have this project where I had the urgent (and temporary) need to have a version control system that has excellent support for branching and merging, so since a week or 2 I've been using Git locally (I'm the only developer on this project for the moment.) So far it has worked really well and it's too bad I won't be able to recommend it for use for the entire group because of the substandard Windows support.  I'm going to check out Mercurial and Subversion, and choose between those two.
|
#
¿
Apr 17, 2009 15:39
|
|
|
|
| # ¿ Apr 27, 2024 19:49 |
|
|
I'm using git on Windows, and I want to configure an external tool (diffmerge) for diffs. I'm supposed to set an option "diff.external" as the command to call the tool. So I did, but when I call "git diff", the external tool isn't called, it just shows the diff right in the git bash shell. It also doesn't complain when I put gibberish in the diff.external option and then call diff. The manual says that the environment variable GIT_EXTERNAL_DIFF would override diff.external, but I don't have it set. I configured diffmerge as an external tool as well, and that does work. I got all the info on how to configure it from http://www.davesquared.net/2009/02/setting-up-diff-and-merge-tools-for-git.html Any ideas?
|
|
#
¿
May 8, 2009 13:32
|
|
|
Question on Mercurial: At some point in the past, I switched from SourceSafe to Git for a project. I didn't convert the repository, I simply turned off the SourceSafe binding, threw away the .ssc files, and created a new Git repository. I now can't stand working with SS any more, so I'm going to push for a switch to Mercurial. (Windows support in Git isn't good enough.) I've tested Mercurial for some other projects and it looks fine. (I only used Git for this one project because I really need something that could branch and merge easily.) Now I have a problem though: I want to convert the SourceSafe projects to Mercurial projects. For most projects that are still in SourceSafe, it'll be easy: just run the conversion script and we're done. For the project I mentioned above though, it's not that easy. I basically have a repository A, converted from SourceSafe, with all the history up to 3 months ago. Then I have another repository B, converted from Git, with history from 3 months ago until today. I there some way to stitch both of them together ? I basically want to say: "revision 1 from repository B now has revision 927 from repo A as a parent", without having to resolve any conflicts. Any ideas how to do this ?
|
|
#
¿
Jun 17, 2009 17:58
|
|
|
uXs posted:... I found how to do this with some help from the mercurial mailing list: a) Make a new repository ('merged'), and pull both repositories. (The second pull will require an -f switch because they're unrelated.) b) Find the full 40-character long revision keys for the revisions that you want to stitch together. These can be found in the shamap file. Put them in a text file on one line (separate with a space), with the revision that is going to become the child first, and the parent revision second. c) run the command 'hg convert merged really_merged --splicemap splice.txt'. (You'll need the convert extension enabled for this.) This will make a repo 'really_merged' that is really merged.
|
|
#
¿
Jun 20, 2009 11:58
|
|
|
As far as I know, pretty much all distributed systems are better at branching and (especially) merging than non-distributed systems. Advising a switch to git or mercurial or whatever doesn't seem too crazy to me. Especially since it's just himself and not an entire company. I basically tried out git for the exact same reason. (I did come from SourceSafe, I guess svn could be a bit better.) And I AM switching the entire company over to Mercurial now 
|
|
#
¿
Aug 7, 2009 17:33
|
|
|
Factor Mystic posted:Is there any way to rename the author of a commit in Mercurial? I accidental skipped a letter in my name when configuring TortoiseHg and now a few recent commits in the repo have the wrong author name. Unfortunately I have also pushed those commits to the bitbucket repo, and it's bugging the hell out of me. My first instinct would be to try the convert extension. There's bound to be some way to map usernames to other usernames there while you do the conversion.
|
|
#
¿
Aug 8, 2009 12:27
|
|
|
supster posted:I'm trying to get some sort of version control working with my remote web server. I set up an SVN repository (on a hosted service) and figured that if I map my remote web server as a drive in Windows (via FTP) then I would be able to use the TortoiseSVN context menus normally in the mapped folder. However they don't appear at all - what are my other options? What are you trying to do here exactly? Why do you need a version control system on your webserver?
|
|
#
¿
Oct 21, 2009 10:00
|
|
|
Use a distributed system. You can do whatever the gently caress you want locally, and synchronize it afterwards.
|
|
#
¿
Oct 21, 2009 22:43
|
|
|
I was assuming that you can develop locally, and then just swap changesets around with whoever else is working on it. And then release to the webserver when something is done. If you really have to develop remotely, which sucks, can't you install a VCS remotely as well? Git and Mercurial or whatever don't require a whole lot of installation (though this can perhaps depend on what kind of system it is, maybe.)
|
|
#
¿
Oct 21, 2009 23:10
|
|
|
supster posted:edit2: and yes, obviously I need local copies of the files to make changes and then push back via FTP - but yes, this process is automated by my editor. So, um, you're making local copies... which you edit... and then copy back? Isn't this like another way of saying that you are developing locally? Then why can't you just version control your local copies?
|
|
#
¿
Oct 22, 2009 08:46
|
|
|
Karanth posted:Nothing's wrong with hg, git just has some really killer features that make it a lot nicer to use once you get the hang of it. The index/staging area http://plasmasturm.org/log/gitidxpraise/ and the pile of ways that git makes screwing around with your repo history easy, for example. If you primarily use that staging area to make partial commits, well, hg can do partial commits too. I do it all the time.
|
|
#
¿
Jan 30, 2010 12:33
|
|
|
Sizzlechest posted:It's a specious argument since a centralized server doesn't require the same kind of merge tracking as a distributed one. There's a single repository everyone is working from. People aren't creating personal branches to work in and then merging them with public ones. They're working from a shared branch or trunk. Merge conflicts get resolved on incremental commits. Merging between branches and the trunk is tracked sufficiently. I suppose you could do private branching in Subversion, but there's no logical reason you'd want to, nor was it designed with that in mind. If two people are working on the same project at the same time, they're already branching the project, whether you choose to call it that or not. Hg/Git choose to make what you're doing clearly visible, SVN tries to hide ite Sizzlechest posted:There's no reason why a private company like the one mentioned needs to implement a distributed system. They don't need have one of them play "merge manager" and reject on a problem like Linus does. They can handle conflicts as they happen, which improves communication. As said before, there's also no reason why a private company shouldn't implement a distributed sytem. gently caress, I'm using Hg to version my personal projects at home, and nobody else is going to ever see that code. Sizzlechest posted:If convenience is the main concern, don't even use a VCS. Nothing is faster or easier to use than a hard drive's file system. If you really believe this, this by itself proves that your opinion is worthless. uXs fucked around with this message at 21:19 on Mar 11, 2010 |
|
#
¿
Mar 11, 2010 21:15
|
|
|
Magicmat posted:Total newbie question here, but why rebase instead of merge in git? I'm trying to think of a good reason (and I assume there must be since everybody uses it so much) but I am failing. It's because of babbies who can't handle a non-linear history, even though a non-linear history is what actually happened. I never used rebase and I can't see why I ever would use it. If you can't see a good reason, don't use it. (And squashing history is even worse: you're not only changing history, you're actually destroying it. Destroying history in a version control system, think about it. Eww.)
|
|
#
¿
Aug 18, 2010 14:25
|
|
|
epswing posted:I've convinced the team to switch to Mercurial! Yay! We have a bunch of repositories on a server (windows box), one for each project. The best way is probably to set up an SSL server somehow, and use that. I have no idea how to do that though, it sounds like it's a pain on Windows. Personally I just use a shared folder (on a server) and push/pull over network shares. Then again, most projects we do is just one person working on something, so we don't get any conflicts. From hanging around in the mercurial IRC channel, I get the impression that this 'solution' is rather frowned upon. On top of that I'm also using hgwebdir as a tool to view the contents of all the repositories. It's pretty great. Look here for how to set it up on IIS: http://vampirebasic.blogspot.com/2009/06/running-mercurial-on-windows.html Even if you stick with using shares or SSL or whatever, I'd still suggest setting up hgwebdir because it's so incredibly useful for browsing repositories (and the entire history) without having to clone them. I think it's possible to set up hgwebdir to allow push access as well, but I haven't looked into that yet. Maybe I should. As for hg serve: it's really not meant as a real, permanent solution, but only in situations where you quickly, temporarily, need a server. About the VS thing: Zhentar already answered you about the VS solution files, but I want to stress that you really need to pay attention to what you include or ignore. I have introduced a ton of people to Mercurial, taking great pains to tell them that they really need to know what they add to a repo, but basically everybody will ignore that and happily include a ton of compiled files that shouldn't be in source control. Especially for the first few projects you need to go over the file list, file by file, to see if they should really be in there. If you're not sure, look it up. After you've done it a few times, your ignore files should be pretty standard so it will be quicker then. (Also check to see if you don't ignore too much. If you think you're done, clone the repo to some other machine and check if it still works.) Edit: quick point about build directories: in most cases you can just ignore everything in there, but there's one exception: websites. In the bin folder you can sometimes find .refresh files. These are pointers to where some referenced DLL files are, and you do need those. Everything else can be ignored. uXs fucked around with this message at 22:14 on Oct 5, 2010 |
|
#
¿
Oct 5, 2010 22:06
|
|
|
Munkeymon posted:Is there any way to pause and restart a clone in git like one might a normal HTTP transfer? Can you do an incremental clone? Get a few changesets at a time, not everything at once. Or you could do the clone from somewhere sane, burn it on dvd, and just copy it. Once you have it, you can link it again to original repo. Changesets from that point should be small enough to work.
|
|
#
¿
Oct 6, 2010 19:01
|
|
|
Mercurial does track renames, but you need to explicitly tell it about them.
|
|
#
¿
Oct 10, 2010 16:46
|
|
|
Wheany posted:So is there a way to tell Mercurial "I don't care about these files" without it deleting them on the next commit? It depends if the files are already in source control or not. hgignore only works for files that Mercurial doesn't know about yet. If they're not under source control yet, you can just add it to .hgignore. If they are under source control, I think hg forget is what you need. (Plus adding them to .hgignore.) But in this case you'll have to coordinate what you're doing with the other devs because otherwise you'll have trouble.
|
|
#
¿
Nov 17, 2010 17:06
|
|
. Thank god for version control
|
What? No it doesn't. Edit: after rereading your first post: it will delete them when you push though (or to be more correct, when you update after a push), which I guess is your problem. If I'm following correctly, you should do: hg forget the files locally, and add them to .hgignore then commit make a backup of the files on the server push your changes to the server, and update it at this point the forgotten files will be deleted on the server, but you have a backup, so put it back Now both locally and on the server the files will be ignored, and your next commits and pushes and updates will all ignore them. Just make sure to never update your server to the changeset where you removed/ignored the files, or any changeset before it. (Also, test all this before you actually do this on a live server. It also wouldn't hurt to experiment some more with deletes and ignores and everything so you really have a good handle on all of this.) (And personally, I'm not a fan of using push&update to deploy stuff to a server. You should have some kind of real deployment script/program that handles all this.) uXs fucked around with this message at 23:27 on Nov 17, 2010 |
|
#
¿
Nov 17, 2010 22:55
|
|
|
epswing posted:My question got skipped Yes.
|
|
#
¿
Dec 13, 2010 17:08
|
|
|
I don't really care. I tag stuff sometimes, and it works for me. As for conflicts, I don't really see where those are coming from. If tags from multiple branches are merged, just add all of them and you're done.
|
|
#
¿
Dec 13, 2010 18:07
|
|
|
epswing posted:
Nothing is stopping you from merging 4.0.1 with 4.1.0, and releasing that as 4.1.1. That will result in another head. Maybe you could merge that into 4.2.0, and release that as 4.2.1. That will still leave you with one head that you can just merge into the main line.
|
|
#
¿
Jan 13, 2011 15:54
|
|
|
Magicmat posted:Won't that result in having to manually fix all the merge conflicts created by the changes from 4.0 to 4.1, and then the same for the changes between 4.1 to 4.2? Or will it just be a fast-forward merge save for the one bugfix?Honest question, because I'm new to DVCS myself. If you have conflicts in the first merge and solve them, I'd think you won't get the same conflicts again in the next one. Fast-forward merges are a git-specific thing as far as I know, with what seems like scary voodoo magic behind the scenes. You could just try it out and see, that's one of the fun things about dvcs. Make a clone and go wild, and if it fails just throw it away again.
|
|
#
¿
Jan 18, 2011 14:13
|
|
|
I tested Git at work (on Windows) and while it worked well for my purposes, I knew I couldn't switch the company over to it because the Windows support isn't a first class priority in Git. For Mercurial on the other hand, Windows support is a critical feature, so I switched us to that. I know it's been said before, but the alternative to Git on Windows isn't Svn, it's Hg.
|
|
#
¿
Apr 15, 2011 17:01
|
|
|
I don't see why you need to make it so complicated, forcing people to use unnatural constructs as rebasing and poo poo. Just write code, branch and merge, it's easy.
|
|
#
¿
May 27, 2011 08:36
|
|
|
Mithaldu posted:Rebasing is incredibly useful as it makes merging easier. Instead of having to resolve ALL the conflicts all at once when merging, you can detach your branch and reattach it at a later commit, then resolve all the conflicts with that, then detach it again and reattach it an even later commit and repeat the process until your branch is based off master. Then you merge it in and have no conflicts. Maybe you could just merge more often?
|
|
#
¿
May 27, 2011 10:17
|
|
|
Mithaldu posted:Yes, of course. I could constantly watch what's happening in the main branch and merge things into my branch, even if i don't know whether i'm happy with my changes as they are. Of course i'll lock the history of my branch in, because fixing issues in a feature branch with "revert blargh" commits is clearly superior to just going back and fixing bad commits. Of course i always have connectivity so there's never a time when i'm not able to stay on top of these things. Of course i'll also happily clutter up my commit history with hundreds of pointless merge commits. But the merges would be what you're actually doing, so they're not pointless. Anyway, whatever. I just wanted to point out that going out of your way to make your development history completely linear isn't the only way to go. In development, branching happens all the time. It's not a crime to have your history show that.
|
|
#
¿
May 27, 2011 15:37
|
|
|
Emo Businessman posted:I am converting a SVN repo to a hg repo and using splicemaps to indicate where merges happened in the original SVN repo, since hg convert doesn't (can't) pick up on that automatically. However, I think I might have cocked it up: It looks ok to me, but that's probably because I look at it the other way around: I do my 'experimental' work in the 'default' branch, and maintenance work is done in a maintenance branch. If you look at it like that, you have your actual development all happening on the left, in a straight line. You start a branch on the right, do some bugfixes in it (half your changesets even start with 'fixed' in the description), merge those fixes in your main branch, do some more fixes, and merge them back in again. Anyway, it's just a way of looking at it, it doesn't really matter. I think they show it like that because it shows the changesets in chronological order, and as much to the left as it can. Even better (or worse), you'll find that the graph can change in appearance from developer to developer, depending on when changesets got pulled and pushed. The only thing that matters here is that changesets have the right parents, and that looks to be the case here.
|
|
#
¿
Aug 11, 2011 10:34
|
|
|
Misogynist posted:uh This always comes up and it's always wrong.
|
|
#
¿
Aug 17, 2011 19:04
|
|
|
Smugdog Millionaire posted:TortoiseSVN is still 5x-50x slicker than either TortoiseGit or TortoiseHG, so I guess everyone should probably be using SVN if they're developing on Windows. Have you used TortoiseHg recently? Not attacking you or anything, just curious.
|
|
#
¿
Aug 18, 2011 10:59
|
|
|
Anyone have experience with the lock extension for Mercurial? Does it actually work? Can it be integrated into TortoiseHg?
|
|
#
¿
Aug 31, 2011 09:22
|
|
|
epswing posted:I've been using mercurial for a couple years now, mostly for small projects with a small number of people working on them. Bugfixes on code that is running in production somewhere. I tag the revision that is released. Then I go on coding new stuff. When I need to fix something in the production code, I go back to the tagged revision, fix the bug in a new branch called 'maintenance', and then merge the fix into default. From then on, more bugfixes all go into the maintenance branch. (Which gets merged into default every time.) Calling the maintenance branch 'maintenance' doesn't do anything except make it more obvious that this is the maintenance branch.
|
|
#
¿
Oct 18, 2011 19:38
|
|
|
epswing posted:Pull from central repo into my main repo. Clone my main repo, update back to the tagged version running in production, fix the code, commit, merge the fix into tip, and push the fix back into my main repo. Which gets pulled into the central repo. We're basically doing the same, except that I don't have to do the cloning. So mine is less work. Also less disk space. Biggest difference though, is that afterwards, I can see which commits were done in maintenance and which were done in default. In mercurial, both methods are pretty much the same. You can have the same functionality with anonymous branches or named branches, with or without clones. There's a small difference in workflow, but the biggest one, to me, is that naming your branches makes it more obvious what you are doing. You can name your branches in clones too, the result would be the same. It's just more work and I don't see the point.
|
|
#
¿
Oct 18, 2011 22:04
|
|
|
Strict 9 posted:I'm setting up Git for me and two other developers. We all work on our own machines and then push our code to a Github repo. The general workflow is: I never understood why people use source control to push things into production. Or why they apparently don't have a test server. Or why they actually build things on their production servers. Or why they have Visual Studio installed on a production server. Maybe it's just me.
|
|
#
¿
Oct 25, 2011 09:05
|
|
|
Mithaldu posted:As long as you're fine with not having the latest and greatest from develop in your feature branch that's all easily doable. But honestly, i'd suggest to gently caress merging and rebase your poo poo. You do feature branches usually because you're the only one working on them, so it's fine to get creative on them. Rebasing also gives you the MASSIVE advantage of being able to rebase up one-by-one and resolve conflicts piece by tiny piece, instead of in one massive merge. Merging is possible step by step too, you know. Admittedly, it won't look pretty :-)
|
|
#
¿
Oct 25, 2011 22:07
|
|
|
VerySolidSnake posted:ColdPie, I appreciate the response! Read this. It's about Mercurial, but explains why a default and a stable branch could be easier to work with than a development and a master branch. Edit: this = http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/ uXs fucked around with this message at 13:48 on Oct 27, 2011 |
|
#
¿
Oct 27, 2011 13:45
|
|
|
Golbez posted:So we finally have git set up but I'm really confused how to handle multiple people merging. Did he actually merge with your things? If he did, he did his merge incorrectly. But I don't know enough about Git to know where exactly.
|
|
#
¿
Nov 4, 2011 15:19
|
|
|
Golbez posted:We're still not sure what went wrong. Since we're converting an existing, non-version controlled codebase to use branches and all that, hiccups are slipping through. He never completed the merge, and now using a tool it seems like he's getting around it, but I'm still not sure. A merge is a pretty simple concept. You have 2 revisions, and need to merge those into 1 revision. So you tell your system that, and it prepares for you a revision that it thinks is a combination of those two. If it can't, it should indicate to you where the problem areas are, and give you the opportunity to merge those areas manually. When that's all done, you can check your work (this is where you should test both your changes as the changes the other guy made), and then commit it.
|
|
#
¿
Nov 4, 2011 17:14
|
|
|
Horse Cock Johnson posted:Is the Mercurial book linked in the OP still the best/most current on the subject? Has Mercurial even changed enough since 2009 for it to even matter? Or is there a more up to date book I should read? I don't know about anything better, but it's probably a bit old. It puts a bit too much emphasis on cloning, while mercurial itself has moved in the direction of named branches.
|
|
#
¿
Nov 28, 2011 20:37
|
|
|
epswing posted:Upgraded from TortoiseHG 1.x to 2.x I think it's like this: If there are conflicts (= changes from different branches in the same file) in some files, it launches the Resolve Conflicts dialog. At this point, it hasn't tried to resolve the conflicts. Then when you do tool resolve, it actually tries to resolve the conflicts itself. If they're trivial, hg can resolve them and it doesn't bother showing you a merge tool. (You can still launch one yourself with the '3-way Diff' button - which is something is ALWAYS do.) But if they're not trivial, it shows you your merge tool.
|
|
#
¿
Feb 9, 2012 12:16
|
|
|
|
| # ¿ Apr 27, 2024 19:49 |
|
|
Flobbster posted:This has me thinking now. We've just started adopting git on some of our two-man projects (moving from CVS on Sourceforge Seems ok to me. Pull. Do work, commit. Repeat that step until you feel like pushing. Then pull & merge anything that changed while you were working, and push. Of cource, if you're one of those weirdos that insists on a linear history, then never mind.
|
|
#
¿
Apr 3, 2012 18:00
|
|
), and we pretty much do the same thing. Each of us clones the repo, does some work, pushes changes back, pulls the other guys'... and it just feels wrong. We've run into some merging issues here and there but we weren't sure how much of that was our fault for not having the best workflow.