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 »

Fly: Nov 3, 2002; moral compass

Dromio posted:

I think the choice of source control systems also says something about the culture of the development group.

My current employer was a startup using VSS. However, changes were afoot when I was hired, and the former senior development team members were on the way out, and with them VSS. Some time later we migrated to Perforce, which is a wonderful tool. This position has been extremely rewarding, and I am glad their use of VSS did not stop me from working here. I would be wary of anyone using VSS or nothing, but what that means for the future depends on the environment. YMMV

# ? Feb 17, 2010 21:55

Adbot: ADBOT LOVES YOU

# ? May 11, 2024 17:58

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

I use lots of TODO comments in my code. I'm now considering using github's issue tracker.

My ideal setup would involve automating issue creation from new TODO comments. Any thoughts on the feasibility of this or if this is just a stupid idea?

# ? Feb 19, 2010 22:05

Fly: Nov 3, 2002; moral compass

Thermopyle posted:

I use lots of TODO comments in my code. I'm now considering using github's issue tracker.

My ideal setup would involve automating issue creation from new TODO comments. Any thoughts on the feasibility of this or if this is just a stupid idea?

Sounds reasonable if you just want to log an issue per file at first, or get a list and then pare it down before programmatically creating issues.

find . -name '*.src' | xargs egrep -l TODO > srcfileswithtodo.txt

# ? Feb 19, 2010 22:47

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

I get the following at the beginning of some lines of the output from SVN status:

code:

?    O *            [filename]

What does the "O" mean? Theres no mention of it in the redbook site page for status.

# ? Feb 24, 2010 14:06

The1ManMoshPit: Apr 17, 2005

According to "svn help st"

quote:

'O' locked in repository, lock token in some Other working copy

# ? Feb 24, 2010 14:14

MononcQc: May 29, 2007

http://hginit.com
Actual nice guide to mercurial for SVN users by Joel Spolsky.

# ? Feb 24, 2010 18:43

bartkusa: Sep 25, 2005; Air, Fire, Earth, Hope

Fly posted:

I cannot imagine why someone would not want to use the main-line model of development, but I'm curious if anyone has "reasons" for sticking with something as perilous as the promotion model.

I work for a large company, which over the past three years has become unimaginably creative at coming up with branching strategies that are not main-line with release branches and project branches.

We're supposed to be better than this

# ? Feb 27, 2010 03:08

Sizzlechest: May 7, 2007

nelson posted:

Well, subversion dumps lots of local meta data files all over the place. When you're copying a directory from a different server to your local directory (this was a porting type project, had to get the latest code from the other developers who were on a separate repository before checking it into my repository), you end up copying all those meta data files too. Unfortunately, it really confuses the hell out of subversion when you do that.

The next major release of Subversion (1.7) is going to offer a working copy scheme like git where all the metadata is in one hidden directory at the root of the WC. The multiple ".svn" directories is my biggest peeve with Subversion. Thankfully, that's going away.

BTW, the most important tip for new users to SVN is to use:

svn add --force .

instead of

svn add *

when you want to make sure you've recursively added everything in your working copy directories, but don't want to accidentally include ignored files. This is especially true for Windows SVN users who have no clue about globbing.

# ? Feb 28, 2010 03:59

Nigel Danvers: Oct 29, 2009

bartkusa posted:

I work for a large company, which over the past three years has become unimaginably creative at coming up with branching strategies that are not main-line with release branches and project branches.

We're supposed to be better than this

You think you've got it bad. The code I work on sounds exactly like yours. It has no trunk, maintains at least 2 products with a shared history where every release of every product is just a branch of the previous release of that product.

My job is to maintain another branch/port of one of these products, but using read-only access to this repository. I need to maintain my own repo so I can keep track of all my changes, while at the same time maintain the link to their repo so I can pull in the latest changes or switch branches when they create a new release and remerge all my code.

Every 6 months they release a new product and I've got the fun code of merging my code again, thankfully so far bzr seems to be doing a great job of managing the brunt of this task.

# ? Feb 28, 2010 13:08

Fly: Nov 3, 2002; moral compass

bartkusa posted:

I work for a large company, which over the past three years has become unimaginably creative at coming up with branching strategies that are not main-line with release branches and project branches.

Are there any reasons for doing so other than short-term expediency?

quote:

We're supposed to be better than this

I doubt the reasons for doing things properly are always immediately evident, which is why having published white papers from Perforce is helpful.

# ? Feb 28, 2010 21:45

stray: Jun 28, 2005; "It's a jet pack, Michael. What could possibly go wrong?"

Janin posted:

I would choose a distributed VCS, rather than Subversion -- my favorite is Bazaar. However, any of the "big 4" (Bazaar, Darcs, Git, Mercurial) should work fine for you.

Thanks, Janin. I decided on Git, since it seems to be a pretty smart system.

I have one more question on Git: do I still need to set up the three folders, trunk, tags and branches with a Git system, or do I not need to worry about that with Git?

Edit:
vvv Ah, thanks. I hadn't done it and I suspected I might not need to, but it's good to know for sure. I definitely like that feature.

stray fucked around with this message at 23:19 on Mar 4, 2010

# ? Mar 4, 2010 22:53

Allie: Jan 17, 2004

stray posted:

Thanks, Janin. I decided on Git, since it seems to be a pretty smart system.

I have one more question on Git: do I still need to set up the three folders, trunk, tags and branches with a Git system, or do I not need to worry about that with Git?

Git has built-in facilities for tagging and branching, so no, definitely do not do that.

# ? Mar 4, 2010 23:01

MonkeyMaker: May 22, 2006; What's your poison, sir?

stray posted:

I have one more question on Git: do I still need to set up the three folders, trunk, tags and branches with a Git system, or do I not need to worry about that with Git?

I know it's been answered but I just want to add, that, no, you don't have to set up anything. Just work. Git will take care of itself (and hg/darcs/bzr/etc seem to do that too).

# ? Mar 4, 2010 23:48

beuges: Jul 4, 2005; fluffy bunny butterfly broomstick

This is probably straightforward, but is it possible to create a new repository, and import a project from an existing repository, along with all of its revision history? I have been storing all of my projects in a single repository, but I'm going to start working with another developer soon, so I'd rather split them out, as I have a bunch of personal stuff stored in my current repo - I'm also toying with the idea of giving my clients read access to their projects via websvn, so I want to create separate repositories for each client, and ideally import all of the existing history for each project into the new repositories as well, rather than just committing the current working copy as an initial revision.

My current idea is to create a repository for each client, and give my dev partner access to the ones he is involved with, rather than having to deal with permissions on a single repository, and likely exposing all my clients even if the actual contents of their projects is restricted.

My tree looks like so:
root
|- personal
|- client1
| |-project1
| |-project2
|-client2
| |-project1
.....

I want to just have separate repositories for each client, with their projects contained therein, cos I don't want client1 to be able to see client2 at the same level as client1, even if client1 can't see the projects inside the client2 area.

# ? Mar 5, 2010 18:14

Pardot: Jul 25, 2001

beuges posted:

This is probably straightforward, but is it possible to create a new repository, and import a project from an existing repository, along with all of its revision history?

You can do this by hand with git filter-branch, or do what I did and use this http://github.com/apenwarr/git-subtree

# ? Mar 5, 2010 18:32

ColdPie: Jun 9, 2006

beuges posted:

This is probably straightforward, but is it possible to create a new repository, and import a project from an existing repository, along with all of its revision history?

You can do this pretty easily with git. First, import all of your repository's history into a temporary git repository (plenty of online tutorials for this). Then do `git rev-list --reverse client1` to get a list of all the commits that touch the client1 directory. Then init a new repository for client1 and cherry-pick those patches in from your temporary svn-import repo.

Something like this, for each client, after importing to git from svn:

pre:

tmp-svn-import$ git rev-list --reverse client1 > ~/client1_commits
tmp-svn-import$ mkdir ~/client1 && cd ~/client1
client1$ git init
client1$ git remote add tmp-svn ~/tmp-svn-import
client1$ git fetch tmp-svn
client1$ git cherry-pick <commit from ~/client1_commits> # write a script do this

I guess you could go from there back to svn, but why you'd ever move from git back to svn I have no idea.

# ? Mar 5, 2010 18:54

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

beuges posted:

My current idea is to create a repository for each client, and give my dev partner access to the ones he is involved with, rather than having to deal with permissions on a single repository, and likely exposing all my clients even if the actual contents of their projects is restricted.

My tree looks like so:
code:
  root
    |- personal 
    |- client1
    |  |-project1
    |  |-project2
    |-client2
    |  |-project1
  .....

You could also run git svn clone --no-metadata svn://your-host/client1/project1 to clone all of that project's history (and only that project's history) into Git.

You can import that back into a different Subversion repository, but that's a bit more complicated (not to mention pointless).

# ? Mar 5, 2010 22:54

Sizzlechest: May 7, 2007

beuges posted:

My tree looks like so:
root
|- personal
|- client1
| |-project1
| |-project2
|-client2
| |-project1
.....

I want to just have separate repositories for each client, with their projects contained therein, cos I don't want client1 to be able to see client2 at the same level as client1, even if client1 can't see the projects inside the client2 area.

First, you need to dump the repository using "svnadmin dump" and then create new dumpfiles of each part of the repository using svndumpfilter. You can then create new repositories and use those filtered dumpfiles to fill it in with just those pieces.

Be careful you don't filter out directories that are copies.

# ? Mar 6, 2010 06:12

beuges: Jul 4, 2005; fluffy bunny butterfly broomstick

people posted:

git

We're going to do at least 90% of our dev in windows and the impression I've gotten from this thread is that the git clients for windows pretty much suck. We could install cygwin and use the cmd line git client but we're already both used to working with tortoise so I'd rather stick with that for now. What I will probably do though, is play around with the git<->svn stuff on my own and see how that works out.

Sizzlechest posted:

First, you need to dump the repository using "svnadmin dump" and then create new dumpfiles of each part of the repository using svndumpfilter. You can then create new repositories and use those filtered dumpfiles to fill it in with just those pieces.

Be careful you don't filter out directories that are copies.

Thanks! Speaking of copies, something that just occurred to me is that I have a bunch of code common to all clients. Obviously using the layout I've described would mean a separate "common" repository. Is there a way to link a project in one repository to a project in another? So as far as client1 is concerned, his tree has project1, project2 and common, but common is actually residing in shared/common instead? Meaning that when i update client2/common for whatever reason, that change also reflects in client1/common?

# ? Mar 6, 2010 10:03

Mine GO BOOM: Apr 18, 2002; If it isn't broken, fix it till it is.

beuges posted:

We're going to do at least 90% of our dev in windows and the impression I've gotten from this thread is that the git clients for windows pretty much suck.

Give Mercurial a try then, as TortoiseHG is great in Windows. They even hit 1.0 yesterday.

# ? Mar 6, 2010 10:46

Sizzlechest: May 7, 2007

beuges posted:

Thanks! Speaking of copies, something that just occurred to me is that I have a bunch of code common to all clients. Obviously using the layout I've described would mean a separate "common" repository. Is there a way to link a project in one repository to a project in another? So as far as client1 is concerned, his tree has project1, project2 and common, but common is actually residing in shared/common instead? Meaning that when i update client2/common for whatever reason, that change also reflects in client1/common?

There is a way to do that where you include files from another repository, but it's more trouble than it's worth.

I'd restructure it so that your "common" directory is a separate repository that's at the same level as the client's code. In other words, structure it so it's two repositories next to each other instead of a repository inside another repository's tree. Don't forget that you can check out a working copy as deep into the repository as you like.

# ? Mar 6, 2010 15:45

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

beuges posted:

the impression I've gotten from this thread is that the git clients for windows pretty much suck.

This isn't true anymore. msysgit is very stable and I enjoy using it on Windows. I was a diehard TortoiseSVN/SmartSVN user and never touched the SVN command line, but there are very few things I use a Git GUI for. Git's command-line interface is just leagues better than SVN's.

I also recommend looking into SmartGit.

# ? Mar 6, 2010 16:28

Dromio: Oct 16, 2002; Sleeper

I'm trying to create a new remote repository for my git repo using the guide I found here. It seems pretty straitforward, but I'm failing.

I'm at my work machine (behind a NAT firewall), trying to push to my home machine. The home machine is running cygwin openssh.

First I ssh into the home machine and do the following:

code:

ssh myhomemachine
mkdir myapp.git
cd myapp.git
git --bare init

Then on my work machine I tried pushing to the home machine:

code:

cd myapp
git remote add origin ssh://myhomemachine/myapp.git
git push origin master

But it fails with "fatal: The remote end hung up unexpectedly". Anyone have any clues on what I might be doing wrong?

# ? Mar 9, 2010 15:17

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

I'm trying to fix a working copy on a guys PC and the Tortoise SVN overlays indicating if something has a local change/conflict ect only appear on directory icons, not individual files, but I can't seem to find an option that would do this, any idea what's going on?

# ? Mar 9, 2010 15:43

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

Dromio posted:

code:

git remote add origin ssh://myhomemachine/myapp.git

Try this instead:

code:

git remote add origin myhomemachine:myapp.git

Git's SSH URLs (like NFS paths) use : to delimit hostnames and paths. You can omit the ssh:// also.

# ? Mar 9, 2010 18:06

MonkeyMaker: May 22, 2006; What's your poison, sir?

Dromio posted:

code:

ssh myhomemachine
mkdir myapp.git
cd myapp.git
git --bare init

I think you need --shared in your init as well.

I think the whole string is:

code:

git --bare init --shared

# ? Mar 9, 2010 18:09

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

He doesn't need --shared:

code:

--shared[={false|true|umask|group|all|world|everybody|0xxx}]
    Specify that the git repository is to be shared amongst
    several users. This allows users belonging to the same
    group to push into that repository. When specified, the
    config variable "core.sharedRepository" is set so that
    files and directories under $GIT_DIR are created with the
    requested permissions. When not specified, git will use
    permissions reported by umask(2).

If he's pushing to his home machine, he's probably the only user who will do so. If multiple people will use this repository, Gitosis is a much better idea anyway.

# ? Mar 9, 2010 18:18

Zhentar: Sep 28, 2003; Brilliant Master Genius

Lysidas posted:

This isn't true anymore. msysgit is very stable and I enjoy using it on Windows. I was a diehard TortoiseSVN/SmartSVN user and never touched the SVN command line, but there are very few things I use a Git GUI for. Git's command-line interface is just leagues better than SVN's.

Not only is the msysgit GUI eye-rape, but when I was trying it out last week trying to checkout a branch would crash it. TortoiseGit is at least usable, although it's still pretty easy to mess up.

# ? Mar 9, 2010 18:29

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

Zhentar posted:

Not only is the msysgit GUI eye-rape, but when I was trying it out last week trying to checkout a branch would crash it. TortoiseGit is at least usable, although it's still pretty easy to mess up.

I can't defend the GUI; I only use gitk. I've never experienced any instability or problems on Windows, especially not a crash (!) when trying to switch branches. git --version tells me "git version 1.6.5.1.1367.gcd48" and I've been using this on several machines with a few different versions of Windows (mostly XP Pro x64 and Server 2003 x86, but also XP Pro x86, Windows 7 x86 and Windows 7 x64). I do some decently complicated branching and merging, too. Have you filed a bug report or Googled around for anyone else who's experienced your problem?

As far as I know, TortoiseGit depends on an external Git executable (e.g. msysgit). SmartGit definitely does. If you had serious problems with msysgit, I'm not sure how TortoiseGit could be more stable.

(I feel like repeating myself for some reason: I couldn't fathom using Subversion without a good GUI (I really enjoyed SmartSVN), but I've found a GUI to be bothersome and useless for Git. Its command line interface is so clean and easy, partially because of the index. I don't have to specify the paths/files as part of the commit command, unlike SVN. Man up and use the CLI :clint:

)

# ? Mar 9, 2010 18:53

Dromio: Oct 16, 2002; Sleeper

Lysidas posted:

Try this instead:
code:
git remote add origin myhomemachine:myapp.git

This worked-- thank you!

I'm not a fan of using the gui for git either. I relied heavily on tortoisesvn to get things done, but with git I feel like it just doesn't cover everything I need. I only want UI tools for diffs and logs.

# ? Mar 9, 2010 20:55

Zhentar: Sep 28, 2003; Brilliant Master Genius

Lysidas posted:

I can't defend the GUI; I only use gitk. I've never experienced any instability or problems on Windows, especially not a crash (!) when trying to switch branches.

The crash was through the GUI, with some of the GUI components, not gitk.

Lysidas posted:

Man up and use the CLI

I really appreciate the Tortoise* explorer integration so I'd rather not.

# ? Mar 11, 2010 16:27

Knackered: Jul 29, 2006

We're looking to start using version control in our system at work.

It's just me and another guy but we think it's best if we have some form of source control and versioning in place. The system is basically a large web app, we have 2 windows machines for coding and a server in another room that we can use to run/testing the code.

My question is this, with so many to choose from, which is the best version control system to go for?

Since we're such a small operation, I was thinking of using a simple SVN over GIT/Mercurial. The plan would be to make the changes, upload them and then test the code by connecting to the server, once we're happy with it we'll push the code out to the actual system.

Of course the other guy if all for using GIT/Mercurial, which I think is over kill.

What do you guys think? What's best for a small team modifying a web application?

# ? Mar 11, 2010 17:31

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

git = good for decentralized; good for merging
svn = good for centralized; windows integration via tortoise; good for naive merging

I would recommend SVN if your case.

# ? Mar 11, 2010 17:36

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

Git or Mercurial, without a doubt. If you're starting from scratch, you have no excuse to use Subversion (centralized version control is obsolete). Distributed version control is never overkill in any situation; actually it's much quicker and easier to get a repository running. Because of this, I use Git to version control things that I never would have thought of before.

I heartily recommend Git, but Mercurial's better Windows support might be better for you. As mentioned earlier in this thread, TortoiseHg is great and just hit 1.0.

# ? Mar 11, 2010 17:42

Vanadium: Jan 8, 2005

Triple Tech posted:

git = good for decentralized; good for merging
svn = good for centralized; windows integration via tortoise; good for naive merging

I would recommend SVN if your case.

What makes git worse for centralized than svn?

# ? Mar 11, 2010 17:46

ColdPie: Jun 9, 2006

Lysidas posted:

Git or Mercurial, without a doubt. If you're starting from scratch, you have no excuse to use Subversion (centralized version control is obsolete). Distributed version control is never overkill in any situation; actually it's much quicker and easier to get a repository running. Because of this, I use Git to version control things that I never would have thought of before.

I heartily recommend Git, but Mercurial's better Windows support might be better for you. As mentioned earlier in this thread, TortoiseHg is great and just hit 1.0.

Completely agreeing with this. Compared to starting a git repository (literally `git init`, then setting up your remotes), setting up all of the poo poo required for SVN is a nightmare. Centralized source control is awful. You require a server to be on all the time, a network connection to be present to do any work, you can't go back and fix your lovely old commits before pushing them public. Unless you're dealing with a lot of large binary files (more than a GB or two), there is no reason to not go with a decentralized model. Plus, you'll make your partner happier.

# ? Mar 11, 2010 17:47

Sizzlechest: May 7, 2007

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:

1. There's a limited and well defined group of people who need access to the system.
2. He's not opening up the source code to the world.
3. His company owns all aspects of the code.
4. It's a networked environment.

There's no real reason to implement a distributed system. Nobody is going to branch the codebase and develop their own flavor for themselves. Nobody has the right to say, "I want to work in private," since that person's work belongs to the company. A distributed setup increases the odds of larger merge conflicts. If you're working on the Linux kernel and don't have an issue with deadlines, then great. In the real world, not so much.

Creating a SVN repository is a single command if you script it, and any SVN admin worth his salt will do so.

You could argue git is easier/better to use, but considering it's a Windows environment, the choice of Subversion is easy.

# ? Mar 11, 2010 18:18

Allie: Jan 17, 2004

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:

1. There's a limited and well defined group of people who need access to the system.
2. He's not opening up the source code to the world.
3. His company owns all aspects of the code.
4. It's a networked environment.

There's no real reason to implement a distributed system. Nobody is going to branch the codebase and develop their own flavor for themselves. Nobody has the right to say, "I want to work in private," since that person's work belongs to the company. A distributed setup increases the odds of larger merge conflicts. If you're working on the Linux kernel and don't have an issue with deadlines, then great. In the real world, not so much.

Creating a SVN repository is a single command if you script it, and any SVN admin worth his salt will do so.

You could argue git is easier/better to use, but considering it's a Windows environment, the choice of Subversion is easy.

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

MonkeyMaker: May 22, 2006; What's your poison, sir?

Sizzlechest posted:

Creating a SVN repository is a single command if you script it, and any SVN admin worth his salt will do so.

Did you miss the part where they're new to all of this?

Seconding the Git/Mercurial rec, especially with TortoiseHg and all the Git versions for Windows.

# ? Mar 11, 2010 18:31

Adbot: ADBOT LOVES YOU

# ? May 11, 2024 17:58

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

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:

1. There's a limited and well defined group of people who need access to the system.
2. He's not opening up the source code to the world.
3. His company owns all aspects of the code.
4. It's a networked environment.

There's no real reason to implement a distributed system. Nobody is going to branch the codebase and develop their own flavor for themselves. Nobody has the right to say, "I want to work in private," since that person's work belongs to the company. A distributed setup increases the odds of larger merge conflicts. If you're working on the Linux kernel and don't have an issue with deadlines, then great. In the real world, not so much.

Creating a SVN repository is a single command if you script it, and any SVN admin worth his salt will do so.

You could argue git is easier/better to use, but considering it's a Windows environment, the choice of Subversion is easy.

No, given that it's a Windows environment, the choice of Mercurial is easy. 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.

A distributed setup does not, in itself, increase the odds of larger merge conflicts. Merging as late as possible increases these odds. What kind of VCS do you think encourages people to delay merging as long as they can? One where repeated merging is painful (and destroys history), or one in which merging is clean, easy and fast? When I have a long-running topic branch, I regularly merge the master branch into it and fix any merge conflicts as they arise. Then, when I merge in the other direction, it's trivial. (Note that this is equivalent to keeping unstable changes in your SVN working copy and repeatedly 'svn up'ing whenever anyone else commits.)

It's absurd to suggest that a DVCS would inspire employees to fork the codebase and never contribute their changes back to the mainline. I do, however, have the right to say "I want to work in private" -- I get to incrementally commit and refine my changes until they're ready to share with others. My experimental branches don't clutter up everyone else's history unless I decide to push them to the central repository, but I can share them if I want to.

I'll go so far as to say that starting from scratch with Subversion is stupid. Even for two people, a distributed system (and the branching capabilities that it comes with) is superior in every way.

# ? Mar 11, 2010 18:43

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

«‹›100 »