Version Control Questions Megathread (SVN / git / whatever else)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »

Allie: Jan 17, 2004

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

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 12:57

Pardot: Jul 25, 2001

Sizzlechest posted:

There's no real reason to implement a distributed system.

There's no reason not to use a dvcs. It's like this

Only registered members can see post attachments!

# ? Mar 11, 2010 18:59

Sizzlechest: May 7, 2007

Milde posted:

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.

So...you're implementing a centralized system?

Milde posted:

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.

You do if you have to look in multiple places for changes committed locally. That's especially fun when someone's out or on travel. With a centralized system, there's ONE place to look for all work in progress.

Milde posted:

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.

Working copy changes in subversion also run instantly. Commits to a centralized server whether in svn or git will take longer, obviously.

Milde posted:

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.

And you don't need a decentralized VCS to accomplish this. The type of branching you're talking about is fast and easy in SVN, too. That's not the kind of branching and merging Linus was talking about when he advocates a decentralized system for Linux. You've got thousands of developers working independently, working on things that may never get into an actual release. They need a way to work on their own and merge later. Two developers working in the same shop don't need to work this way, nor is it advantageous for them to do so.

Milde posted:

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.

When git first came out, SVN was at 1.4 and it's merging was complete poo poo. In the latest version (1.6), it keeps track of branches and merges just fine. What's more annoying? Resolving a little merge conflict now or a fuckton later?

# ? Mar 11, 2010 19:08

Sizzlechest: May 7, 2007

Pardot posted:

There's no reason not to use a dvcs. It's like this

Even easier:

# ? Mar 11, 2010 19:16

ColdPie: Jun 9, 2006

Sizzlechest posted:

Even easier:

Yes, I love limiting myself for absolutely no benefit!

# ? Mar 11, 2010 19:17

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

Milde posted:

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.

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

I primarily use command-line tools, and I've completely fallen in love with the index. I'm a big fan of staging only parts of a file; it's a neat feature. I also really like the ease with which Git lets you rewrite history -- as far as I know, Mercurial doesn't ship with features like rebasing, commit amending, etc. (not to mention git filter-branch).

Essentially, I understand Git a lot better than Mercurial, so I see it as easier to use. _{("what? you mean hg pull doesn't merge? that's stupid")} I should probably stop stating this as objective truth :downs:

# ? Mar 11, 2010 19:17

Sizzlechest: May 7, 2007

ColdPie posted:

Yes, I love limiting myself for absolutely no benefit!

And I love making my life unnecessarily more complicated for absolutely no benefit.

# ? Mar 11, 2010 19:20

ColdPie: Jun 9, 2006

Sizzlechest posted:

And I love making my life unnecessarily more complicated for absolutely no benefit.

Haha, did you just say git is more complicated than subversion?

# ? Mar 11, 2010 19:20

Sizzlechest: May 7, 2007

ColdPie posted:

Haha, did you just say git is more complicated than subversion?

No, I said you're cockamamie hybrid setup is.

# ? Mar 11, 2010 19:26

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

Sizzlechest posted:

No, I said you're cockamamie hybrid setup is.

I believe that was a Venn diagram that illustrated the capabilities of different VCS types, and not a suggestion to use git-svn or something equivalent.

# ? Mar 11, 2010 19:30

Pardot: Jul 25, 2001

Lysidas posted:

I believe that was a Venn diagram that illustrated the capabilities of different VCS types, and not a suggestion to use git-svn or something equivalent.

This statement is correct.

# ? Mar 11, 2010 19:33

Allie: Jan 17, 2004

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

I primarily use command-line tools, and I've completely fallen in love with the index. I'm a big fan of staging only parts of a file; it's a neat feature. I also really like the ease with which Git lets you rewrite history -- as far as I know, Mercurial doesn't ship with features like rebasing, commit amending, etc. (not to mention git filter-branch).

Essentially, I understand Git a lot better than Mercurial, so I see it as easier to use. _{("what? you mean hg pull doesn't merge? that's stupid")} I should probably stop stating this as objective truth

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

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

Sizzlechest posted:

So...you're implementing a centralized system?

You do if you have to look in multiple places for changes committed locally. That's especially fun when someone's out or on travel. With a centralized system, there's ONE place to look for all work in progress.

You don't seem to get decentralized version control. In almost all cases, there is one central place where the code lives, but that should be a social/organizational distinction and not a technical one. Linus' kernel tree is a great example. That's the single canonical place for the kernel source, but that doesn't mean that Linux uses a centralized development model :confused:

Linus said it much better than I will: http://lwn.net/Articles/246381/

In a development organization, changes should eventually make their way into a central repository. A DVCS gives you a lot of freedom in how this happens (like through a single person who collects changes, for example).

Sizzlechest posted:

Working copy changes in subversion also run instantly. Commits to a centralized server whether in svn or git will take longer, obviously.

What are you trying to say here? The point is that there's a lot more you can do locally with a DVCS.

Sizzlechest posted:

And you don't need a decentralized VCS to accomplish this. The type of branching you're talking about is fast and easy in SVN, too. That's not the kind of branching and merging Linus was talking about when he advocates a decentralized system for Linux. You've got thousands of developers working independently, working on things that may never get into an actual release. They need a way to work on their own and merge later. Two developers working in the same shop don't need to work this way, nor is it advantageous for them to do so.

When git first came out, SVN was at 1.4 and it's merging was complete poo poo. In the latest version (1.6), it keeps track of branches and merges just fine. What's more annoying? Resolving a little merge conflict now or a fuckton later?

I've already addressed your merge conflict strawman, but you either didn't notice it or chose to ignore it.

Subversion absolutely does not keep track of branching and merging "just fine".

When merging, the entire branch is squashed into a single commit that appears to have been written by the merge committer.
SVN's default log operation doesn't show you the branch's commits; you have to view the entire repository at some previous revision that isn't immediately obvious.
--reintegrate is just silly

As the Subversion book says, "The bottom line is that Subversion's merge-tracking feature has an extremely complex internal implementation, and the svn:mergeinfo property is the only window the user has into the machinery." This just screams to me that the Subversion devs painted themselves into a corner with merging, and the best thing to do is scrap the system and redesign it from scratch. Incidentally, this is exactly what happened with Git, Mercurial, and others!

# ? Mar 11, 2010 19:53

Vanadium: Jan 8, 2005

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!

# ? Mar 11, 2010 19:54

Allie: Jan 17, 2004

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

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

I'd heard that Mercurial didn't have lightweight local branches like Git, then heard that it did, but I didn't realize that it was through an extension and that these bookmarks can't be easily pushed or pulled. Git's local branches seem much easier to me. I just remembered that I strongly dislike using .hgtags -- I think it's bizarre that you can check out a tag, but immediately after doing that, the tag kind-of no longer exists.

Git got it right; branches and tags are just pointers to commits. Tags don't move, but branches do.

Mercurial's command set seems simpler, but Git's history model makes much more sense to me. I believe that this is the difference between 'simple' and 'easy': Mercurial is easier to start using, but Git's design makes a lot more sense.

# ? Mar 11, 2010 20:11

Allie: Jan 17, 2004

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

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Lysidas posted:

What are you trying to say here? The point is that there's a lot more you can do locally with a DVCS.

Pretty sure he's saying that he would want everything everyone is working on to be stored in one place that's obvious and accessible. The best way to do that is to force them to use a central repository and the best way to do that is to lock them into a system where they can pretty much only do things that way. Enforcing management decisions like that through technical limitations is also pretty popular though obviously not ideal.

And yes it does make some sense from the perspective of a manager who can't spare the time to comb through team members' machines looking for the repository they were working on that new feature in that they never bothered to push to the central repository because they didn't know ahead of time there was going to be a death in the family last night (or some similar situation). Clearly that's not going to happen often, but avoiding it might take a higher priority in some minds than everyday convenience.

# ? Mar 11, 2010 20:26

Sizzlechest: May 7, 2007

Lysidas posted:

You don't seem to get decentralized version control. In almost all cases, there is one central place where the code lives, but that should be a social/organizational distinction and not a technical one. Linus' kernel tree is a great example. That's the single canonical place for the kernel source, but that doesn't mean that Linux uses a centralized development model

The reason that's an advantage for Linus is because he can't predict how those changes make it up the "chain of trust" to him. The people on the bottom don't even have access to his repository. Their changes get submitted to intermediaries, merged, and passed on.

There's good reason form him to do this for the kernel. There's no good reason to do this in a closed environment with a fixed and known group of people.

Lysidas posted:

What are you trying to say here? The point is that there's a lot more you can do locally with a DVCS.

Who cares? Adding, deleting, etc. are all local for Subversion. Incremental changes committed to a central repository vs. big(ger) commits to a master server later is not a big difference.

Lysidas posted:

...stuff about merging...

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.

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.

Munkeymon posted:

Clearly that's not going to happen often, but avoiding it might take a higher priority in some minds than everyday convenience.

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.

Sizzlechest fucked around with this message at 20:32 on Mar 11, 2010

# ? Mar 11, 2010 20:30

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Sizzlechest posted:

There's no reason why a private company like the one mentioned needs to implement a distributed system.

I'm fairly noobish when it comes to this stuff...but I think the argument you need to make is why shouldn't they use a DVCS.

# ? Mar 11, 2010 20:44

hey mom its 420: May 12, 2007

This is a constant back and forth discussion here on SA. People will claim how you should use SVN because it's "good enough" and "you don't need more". Even after being faced with arguments that distributed version control systems can do pretty much everything that centralized ones can do and that they can do it better.

# ? Mar 11, 2010 20:59

hey mom its 420: May 12, 2007

Milde posted:

The only real reason not to use Git or Mercurial is if you need to version large binaries.

This is pretty much it. Or if you need some crazy integration with your lame IDE that only works with SVN.

# ? Mar 11, 2010 21:03

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

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.

Your argument appears to have changed from "you can branch and merge with Subversion just fine" to "well, you don't really need to branch anyway". Classic SVN brainwashing. I'm a single developer working on my company's website, and the Git history isn't anywhere near linear. I make topic branches very often (for larger changes) and merging is completely painless.

If you're not making branches, then what do you do with experimental changes that aren't ready to go live yet? Do they sit in your working copy until they're ready to commit? (That's a horrible idea.) Do you commit them to the trunk? (That's even worse; what happens if you need to quickly fix a bug, but your experimental changes are mixed in with other important bug fixes that you can't easily cherry-pick?)

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.

Like I said, you don't appear to get distributed version control. The tool doesn't force you to use an integration manager or dictator/lieutenant workflow like the Linux kernel. The tool doesn't force any kind of workflow at all! (Again, you're showing symptoms of Subversion brainwashing; a centralized version control systems does force a certain workflow.)

I absolutely agree that two people should use a centralized workflow -- both of them have individual repositories and have push access to the central repository. DVCS tools are still have vastly superior features.

Thermopyle posted:

I'm fairly noobish when it comes to this stuff...but I think the argument you need to make is why shouldn't they use a DVCS.

This is absolutely correct. Sizzlechest's argument is "it's too hard", which was refuted some time ago. DVCSes are easier to set up, easier to collaborate with, easier to branch and merge with, faster to work with, allow disconnected operation and are generally superior in every way.

# ? Mar 11, 2010 21:03

uXs: May 3, 2005; Mark it zero!

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

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

Bonus posted:

This is a constant back and forth discussion here on SA. People will claim how you should use SVN because it's "good enough" and "you don't need more". Even after being faced with arguments that distributed version control systems can do pretty much everything that centralized ones can do and that they can do it better.

Hell, this happened a few pages ago in this thread. At the time, I wasn't as experienced with Git and I hadn't yet Seen The Light. Now that I have, I'm an enormous jackass to anyone who suggests starting from scratch with Subversion.

# ? Mar 11, 2010 21:21

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Lysidas posted:

Hell, this happened a few pages ago in this thread. At the time, I wasn't as experienced with Git and I hadn't yet Seen The Light. Now that I have, I'm an enormous jackass to anyone who suggests starting from scratch with Subversion.

I'm concerned that this is me now since I initially recommended Subversion and I have zero experience with Git. Just going off of gut and old initial reactions of Git when tool support was still very fresh. Times have since changed, obviously.

I'm not opposed to learning Git, but I just have no impetus to! My office uses Subversion and I know with our "schedule" and calibur Git would be out of the question. And, I don't have the cycles or motivation to take up an open source project that uses Git.

# ? Mar 11, 2010 21:30

hey mom its 420: May 12, 2007

Yeah, if you have everyone already using SVN and the team has found a good workflow, switching to another VCS just isn't worth it sometimes. However, we're mostly saying about new projects.
Also, in my experience, Mercurial has a much easier interface than git, so mostly I'd recommend going for it over git if you have several people that have to learn a new VCS.

# ? Mar 11, 2010 21:45

ColdPie: Jun 9, 2006

Bonus posted:

Yeah, if you have everyone already using SVN and the team has found a good workflow, switching to another VCS just isn't worth it sometimes. However, we're mostly saying about new projects.
Also, in my experience, Mercurial has a much easier interface than git, so mostly I'd recommend going for it over git if you have several people that have to learn a new VCS.

Git has the advantage of being more widely used, at least in the OSS world. Depending on your domain, it might make sense to stick with the crowd. Having never used Hg, I can't say anything about usage differences, though I would sorely miss the index.

Edit: Either way, once you've learned one, I'm sure it's not hard to switch to the other.

# ? Mar 11, 2010 21:51

hey mom its 420: May 12, 2007

On the other hand, if you need Windows support (and you're not working on a project that already uses git), Mercurial might be your thing. Bottom line, both Mercurial and git are great, everything else is a matter of personal preference I guess.

# ? Mar 11, 2010 22:04

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

FWIW, I had never used a VCS before a month or so ago. I got up and running with git/github/mysgit and it was easy as pie.

# ? Mar 11, 2010 22:13

Sizzlechest: May 7, 2007

Bonus posted:

This is a constant back and forth discussion here on SA. People will claim how you should use SVN because it's "good enough" and "you don't need more". Even after being faced with arguments that distributed version control systems can do pretty much everything that centralized ones can do and that they can do it better.

No. It's a matter of whether or not you intend on implementing a distributed vcs as a distributed vcs. People keep crowing about how centralized vcs is obsolete, when that's exactly what they end up doing.

Lysidas posted:

Your argument appears to have changed from "you can branch and merge with Subversion just fine" to "well, you don't really need to branch anyway". Classic SVN brainwashing. I'm a single developer working on my company's website, and the Git history isn't anywhere near linear. I make topic branches very often (for larger changes) and merging is completely painless.

Wrong. The need for merge tracking in a distributed VCS is more demanding because of the way it's used in a distributed environment. It's like complaining a car is worthless because it can't float. That's not how cars were meant to be used.

Lysidas posted:

If you're not making branches, then what do you do with experimental changes that aren't ready to go live yet? Do they sit in your working copy until they're ready to commit? (That's a horrible idea.) Do you commit them to the trunk? (That's even worse; what happens if you need to quickly fix a bug, but your experimental changes are mixed in with other important bug fixes that you can't easily cherry-pick?)

You do what you're supposed to do, make a public branch and let everyone have access to the changes you're making. All it takes is for the other users to do a "svn update" and all the updates commited to the repository are in their working copy. Nobody has to wait for the "merge nanny" to make all the changes available.

Lysidas posted:

Like I said, you don't appear to get distributed version control. The tool doesn't force you to use an integration manager or dictator/lieutenant workflow like the Linux kernel. The tool doesn't force any kind of workflow at all! (Again, you're showing symptoms of Subversion brainwashing; a centralized version control systems does force a certain workflow.)

It is you who doesn't understand how distributed vcs works. Distributed version control has a workflow, otherwise changes would never get up the chain to be released. The workflow relies on individuals collecting changes from people they trust and pass them on to people higher up the chain who trust them. It's extremely flexible and powerful for large open source projects like the Linux kernel and is completely useless for the OP's needs.

Lysidas posted:

I absolutely agree that two people should use a centralized workflow -- both of them have individual repositories and have push access to the central repository. DVCS tools are still have vastly superior features.

I think I see the conflict here. You're mixing up the tool (git) with the concept of a distributed vcs. Yes, they could use git as a centralized repository. Setting up authentication and authorization in a Windows environment is going to be a lot more difficult. With subversion, the default install with Apache on a Windows server allows browser based authentication out of the box.

Sizzlechest fucked around with this message at 22:39 on Mar 11, 2010

# ? Mar 11, 2010 22:37

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Sizzlechest posted:

No. It's a matter of whether or not you intend on implementing a distributed vcs as a distributed vcs. People keep crowing about how centralized vcs is obsolete, when that's exactly what they end up doing.

I keep re-reading this paragraph, but no matter how hard I try, it never makes any sense.

SVN doesn't support branching. I can't branch from the main repository to my workstation, make commits locally, and then merge them back. This is why SVN, or any centralized VCS, are awful to use.

Bazaar/Mercurial/Darcs/Git do support branching. I can branch from the main repository to my workstation, make commits locally, and then merge them back. This is the entire purpose to distributed VCS.

# ? Mar 12, 2010 03:34

ToxicFrog: Apr 26, 2008

Sizzlechest posted:

It is you who doesn't understand how distributed vcs works. Distributed version control has a workflow, otherwise changes would never get up the chain to be released. The workflow relies on individuals collecting changes from people they trust and pass them on to people higher up the chain who trust them. It's extremely flexible and powerful for large open source projects like the Linux kernel and is completely useless for the OP's needs.

You seem to be conflating "distributed version control software" and "distributed kernel-style workflow". DVCSes are, as a rule, versatile; you can organize your project, but you are not required to.

For example, last semester, I used git for a few group projects. The actual workflow was similar to how we would use a centralized VCS - there was a central reference repository which everyone pushed to and pulled from, with master representing the definitive state of the project.

Why didn't we just use SVN, you ask? Because git took us all of thirty seconds to set up, and furthermore supports tags, branches, private branching, offline commits, and stashing, to name just a few features we all made heavy use of, and svn does not.

The fact of the matter is, if you want an svn-like workflow with a central repository that everyone talks to, you can do that with a DVCS - while at the same time gaining access to a host of useful features that centralied VCSes simply do not have. Saying "distributed version control is a bad fit for this project because they don't want to use linux-kernel-dev style workflow" borders on the nonsensical.

# ? Mar 12, 2010 06:26

Zhentar: Sep 28, 2003; Brilliant Master Genius

So I keep hearing that git/mercurial do better merging than SVN, but aside from the branch commit history (which I don't care about), I'm not really clear on why. Can someone provide/point me at a real world example where git/mercurial will perform the merge correctly and SVN will not?

Janin posted:

SVN doesn't support branching. I can't branch from the main repository to my workstation, make commits locally, and then merge them back.

You have an interesting definition of branching.

# ? Mar 12, 2010 17:20

musclecoder: Oct 23, 2006; I'm all about meeting girls. I'm all about meeting guys.

Zhentar posted:

So I keep hearing that git/mercurial do better merging than SVN, but aside from the branch commit history (which I don't care about), I'm not really clear on why. Can someone provide/point me at a real world example where git/mercurial will perform the merge correctly and SVN will not?

You have an interesting definition of branching.

It's not the correctness (although I'm sure you can find merging bugs in either), its the ease of workflow, at least for me.

Merging in Subversion (1.5+ where merge tracking exists):

code:

svn merge http://svn.site.com/full/repository/path/ . --dry-run (and then, do I use --reintegrate here, or not? I can never remember, etc.)

Ok, everything looks good.

code:

svn merge http://svn.site.com/full/repository/path/ . && svn ci -m "Alright, just merged this from that."

So you either have to have a working copy of one branch and svn switch between them, or a working copy of both.

Git is 100x easier:

code:

git checkout -b new-branch-name; # create a new branch new-branch-name and switch to it
# hackity hack, checkin.
git checkout master; # switch back to master branch
git merge new-branch-name;

That's it. I was a subversion devotee too, but you should really give git/hg a shot. Github.com is great, and it's like everyone else has been saying: git does everything subversion does, only easier, faster, and more intuitively, so why not use it?

# ? Mar 12, 2010 19:24

Sizzlechest: May 7, 2007

musclecoder posted:

Git is 100x easier:

code:

git checkout -b new-branch-name; # create a new branch new-branch-name and switch to it
# hackity hack, checkin.
git checkout master; # switch back to master branch
git merge new-branch-name;

SVN:

code:

svn copy trunk branch
svn switch branch
# hackity hack, checkin.
svn switch trunk
svn merge --reintegrate branch trunk

EDIT: used "switch" to make it closer to original example.

Sizzlechest fucked around with this message at 20:42 on Mar 12, 2010

# ? Mar 12, 2010 20:28

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

In case you didn't know, the msysgit version of Git 1.7.0.2 was released a few days ago.

If you're using 1.6.5.1, I strongly recommend updating. Apparently there has been a lot of work in the Git mainline to make it perform better on Windows, and it definitely shows in this release. It feels much snappier to me.

# ? Mar 12, 2010 20:29

good jovi: Dec 11, 2000; 'm pro-dickgirl, and I VOTE!

Zhentar posted:

You have an interesting definition of branching.

A proper definition. Subversion supports branching in the same way that a filesystem supports branching. There is a common convention that subversion users learn and refer to as "branching", but that don't make it so.

# ? Mar 12, 2010 21:29

opie: Nov 28, 2000; Check out my TFLC Excuse Log!

I hope this is the right place for this, or maybe I should make my own thread. I'm not responsible for version control nor do I know a lot about it, but I am responsible for making the tools for our code work with the rules set up by our version control manager. Unfortunately I am struggling to do this within TFS.

Our tools are written around our source code being mapped to L:. But opening solutions from L: breaks the bindings to source control in TFS. Is there a way to get this to work?

# ? Mar 19, 2010 00:28

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 12:57

Mithaldu: Sep 25, 2007; Let's cuddle.

Quick note for the people going "git sucks on windows". I know this was true in the past and it kept me from switching from SVN to it. However as of this point in time that's absolutely not true anymore.

Using GitExtensions and TortoiseGit you get literally everything you need in a perfectly comfortable manner even on windows.

GitExtensions handles committing perfectly and allows you to quickly dump hunks or single lines into your commit simply by clicking on them. TGit paired with Putty's pageant handles branching, diffing, logs, merging and most importantly, connectivity to remote repos with ssh keys completely transparently for you.

Nowadays I feel frustrated with SVN whenever i want to split large changes into multiple commits because i can only commit all in one go or have to massage the files instead of just selecting which lines i want to commit.

# ? Mar 19, 2010 18:00

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »