|
Dromio posted:I think the choice of source control systems also says something about the culture of the development group.
|
# ? Feb 17, 2010 21:55 |
|
|
# ? May 16, 2024 18:46 |
|
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 |
|
Thermopyle posted:I use lots of TODO comments in my code. I'm now considering using github's issue tracker. 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 |
|
I get the following at the beginning of some lines of the output from SVN status:code:
|
# ? Feb 24, 2010 14:06 |
|
According to "svn help st"quote:'O' locked in repository, lock token in some Other working copy
|
# ? Feb 24, 2010 14:14 |
|
http://hginit.com Actual nice guide to mercurial for SVN users by Joel Spolsky.
|
# ? Feb 24, 2010 18:43 |
|
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 |
|
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 |
|
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. 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 |
|
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. quote:We're supposed to be better than this
|
# ? Feb 28, 2010 21:45 |
|
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. 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 |
|
stray posted:Thanks, Janin. I decided on Git, since it seems to be a pretty smart system. Git has built-in facilities for tagging and branching, so no, definitely do not do that.
|
# ? Mar 4, 2010 23:01 |
|
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 |
|
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 |
|
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 |
|
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
|
# ? Mar 5, 2010 18:54 |
|
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. 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 |
|
beuges posted:My tree looks like so: 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 |
|
people posted:git 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. 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 |
|
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.
|
# ? Mar 6, 2010 10:46 |
|
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 |
|
beuges posted:the impression I've gotten from this thread is that the git clients for windows pretty much suck. I also recommend looking into SmartGit.
|
# ? Mar 6, 2010 16:28 |
|
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:
code:
|
# ? Mar 9, 2010 15:17 |
|
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 |
|
Dromio posted:
code:
|
# ? Mar 9, 2010 18:06 |
|
Dromio posted:
I think you need --shared in your init as well. I think the whole string is: code:
|
# ? Mar 9, 2010 18:09 |
|
He doesn't need --shared:code:
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 |
|
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 |
|
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. 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 )
|
# ? Mar 9, 2010 18:53 |
|
Lysidas posted:Try this instead: 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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Triple Tech posted:git = good for decentralized; good for merging What makes git worse for centralized than svn?
|
# ? Mar 11, 2010 17:46 |
|
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. 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 |
|
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 |
|
Sizzlechest posted:He's looking to set up a repository at work. He didn't explicitly say it, but I'm going to go out on a limb and guess the following are true: These are all bullshit reasons. 1. You can do fine-grained access control in a distributed system: your central repo server would enforce these rules. 2. You don't lose control over the source code just because you're using a distributed system any more than with a centralized system. 3. Even if you have a great network, having most commands run instantly is still a plus. It's even more useful if you're telecommuting or you have multiple locations. 4. Branching doesn't just mean making a "flavor" of a codebase: you branch when you want to implement a large feature without loving up the current main code base, you branch when you need to maintain old maintenance branches. 5. If you're branching in svn, you're gonna have to do merges no matter what. With Git or Mercurial it's most likely going to be a lot easier. They're just better at branching. If all your devs are using one svn repo, well, then you're all gonna be doing a tons of mini-merges with each svn up, which is annoying as gently caress. The only real reason not to use Git or Mercurial is if you need to version large binaries. Where I work we migrated from Subversion to Mercurial, and it's been great.
|
# ? Mar 11, 2010 18:29 |
|
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 |
|
|
# ? May 16, 2024 18:46 |
|
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: 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 |