|
Mithaldu posted:You should mention what VCS this is with. Also: You should move to another one, as a VCS that is based on XML probably sucks hard. Sorry, SVN. I think it might actually be referring to the file being committed, which is in XML format.
|
#
?
Dec 6, 2010 14:46
|
|
|
|
| # ? May 10, 2024 09:16 |
|
|
BizarroAzrael posted:Sorry, SVN. I think it might actually be referring to the file being committed, which is in XML format. Ask your SVN maintainer what hooks they have set up.
|
|
#
?
Dec 6, 2010 14:48
|
|
|
ColdPie posted:Ask your SVN maintainer what hooks they have set up. Turns out SVN has been configured to check XML files for validity, and this one had a "£" in it, which is a no-no. Committed fine with that removed. I just issued this command: svn update --non-interactive -r{12062010T2200} [dir] But it seems to have gone a revision early, there is one more commit that was made after the revision the directory updated to but before 10PM last night, anyone know why that might be?
|
|
#
?
Dec 7, 2010 15:25
|
|
|
My question got skipped  http://forums.somethingawful.com/showthread.php?threadid=3113983&pagenumber=15&perpage=40#post383276306 When going back to fix a bug in an old tagged version, and merging back into the main line of development, shouldn't I clone/update to the rev after the tag to avoid that pesky .hgtags merge conflict?
|
|
#
?
Dec 13, 2010 15:54
|
|
|
epswing posted:My question got skipped Yes.
|
|
#
?
Dec 13, 2010 17:08
|
|
|
Mercurial Wiki:quote:The fact that tags identify changesets and are also parts of changesets has some potentially confusing implications: Mercurial Guide: quote:An unfortunate consequence of this design is that you can't actually verify that your merged .hgtags file is correct until after you've committed a change. So if you find yourself resolving a conflict on .hgtags during a merge, be sure to run hg tags after you commit. If it finds an error in the .hgtags file, it will report the location of the error, which you can then fix and commit. You should then run hg tags again, just to be sure that your fix is correct. Do you generally find versioned tags useful, or is this an over-engineered "feature" that you find annoying? epswing fucked around with this message at 17:15 on Dec 13, 2010 |
|
#
?
Dec 13, 2010 17:10
|
|
|
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
|
|
|
Using git, how can I move all my commits since my last push to github to a new branch? After doing a bunch of work and commits on my master branch, I decided that I need all that work to be on a new branch...
|
|
#
?
Dec 16, 2010 19:13
|
|
|
Thermopyle posted:Using git, how can I move all my commits since my last push to github to a new branch? Off the top of my head... git checkout -b newbranch creates newbranch at your current commit, and switches you to it. Then, git branch -f master origin/master moves the master branch to point at upstream's master.
|
|
#
?
Dec 16, 2010 19:22
|
|
|
Cute headline from proggit: "Git, complicated? Of course not! Commits map to isomorphic contours in source-code phase space." http://tartley.com/?p=1267 quote:it’s simplest to think of the state of your repository as a point in a high-dimensional ‘code-space’, in which branches are represented as n-dimensional membranes, mapping the spatial loci of successive commits onto the projected manifold of each cloned repository.
|
|
#
?
Dec 16, 2010 20:27
|
|
|
Thermopyle posted:Using git, how can I move all my commits since my last push to github to a new branch? Branches are really little more than user-friendly names for commit IDs. To make a new branch at an arbitrary commit ID: git branch <new-branch-name> <commit-id> To change what commit your current branch is a name for, you reset it: git reset <commit-id> So, to answer your question, first make a new branch with whatever commit ID you want it to point to: git branch some-topic-branch abcd1234 Then, checkout master if it isn't already and reset it to the commit that origin/master points to: git checkout master git reset origin/master To sync your current work tree to the state of the tree that your current HEAD points to, just do: git reset --hard HEAD There are shortcuts and such that can make this less typing, but this is explicitly what you want to do. As an alternative, you could just rename your current branch and then re-create your master branch: git checkout master git branch -M some-topic-branch git branch master origin/master git checkout master ColdPie fucked around with this message at 02:11 on Dec 17, 2010 |
|
#
?
Dec 17, 2010 02:09
|
|
|
I don't do much with version control, as far as managing the actual repository goes. I just check out and commit my code, following the processes others have defined. That said, I started a new job a couple months ago and there's a pretty big difference in their approach to source control than my previous job. In the previous job, every project got its own branch and was developed in a vacuum. After you made all your changes and your project was done and ready for QA, you would go through a merge process to get other code other developers changed in their projects before commiting to the trunk. This was at a multi-thousand developer company with a massive integrated software suite, all running from one repository. The new position is a much smaller group (actually a much bigger company, but we are one small group with its own application) and we have our own repository. Our approach is that each release gets its own branch and all of the developers check code out from there and commit changes to it directly. We regularly update our local code from the branch to get changes from others and commit anytime our code is relatively stable. The tech lead then merges from the branch to the trunk after each release and creates a new branch for the next release. So far, I'm much preferring the second approach, as I'm running into fewer conflicts and getting someone else's in-progress code has been as simple as running an update, rather than checking out their branch and doing a merge. But something about this approach strikes me as "non-robust." Is one of these approaches "more right" than the other? Is there a "typical" verson control scheme that others follow? These are the only two jobs where I've used version control, so I don't really have any reference for what's normal.
|
|
#
?
Dec 18, 2010 16:47
|
|
|
It's not a matter of "more right" in the absolute sense. It's whatever works for the environment. Smaller groups with lots of direct communication can benefit from a centralized setup. Resolving conflicts earlier rather than later can save a lot of time and effort. When there are thousands of coders, it can be chaos.
|
|
#
?
Dec 18, 2010 17:48
|
|
|
Thanks for the help on moving working dir to a new branch guys. Another git question. I just started working on someone elses repo on github and apparently they commit CRLF. I can't for the life of me figure out how to get git to convert to LF on my end. I've tried: Setting core.autocrlf to True. Setting core.autocrlf to False. Setting core.eol to native. Setting core.eol to lf. The various combinations of the above two settings None of that works. Is this not possible?
|
|
#
?
Dec 19, 2010 04:48
|
|
|
Does anyone know how to set the executable bit using bazaar? I've been googling for a while and can't find out how to do it, only that bazaar supports it.
|
|
#
?
Dec 19, 2010 17:41
|
|
|
With a really large, really old project, is it theoretically possible that updating a really old (year +) project will be slower than a completely fresh checkout. I have been trying the update for days, though it may just be a couple of server resets responsible.
|
|
#
?
Dec 20, 2010 16:12
|
|
|
I'm having a little trouble setting up an SVN repository with authentication. My stack is CentOS 5.4 and RPMForge's subversion 1.6.15. I have successfully set up svnserve to serve SVN access off of xinetd with no authentication. I then added SASL to my svnserve.conf and used /usr/sbin/saslpasswd2 to add a user/password combination. However, upon connecting to the server, it gives me three tries with my username and password, which fails and gives me this error message: code:code:code:code:
|
|
#
?
Dec 20, 2010 16:35
|
|
|
BizarroAzrael posted:With a really large, really old project, is it theoretically possible that updating a really old (year +) project will be slower than a completely fresh checkout. I have been trying the update for days, though it may just be a couple of server resets responsible. What VCS are you using? With a centralized system, it'll probably be about as fast either way. It's just fetching the latest files and putting them into your working copy. With a distributed system, it'll definitely be faster to do an update rather than a new clone. An update just fetches the new data, while a new clone would re-fetch all data.
|
|
#
?
Dec 20, 2010 19:57
|
|
|
Can anyone recommend an issue tracker that can be used in a distributed fashion? Ideally I want something with minimal dependencies along the lines of TiddlyWiki, but tailored to issue tracking, and able to cope with a little light merging. Installing Python etc is not an option, but I do at least have access to a modern browser.
|
|
#
?
Dec 21, 2010 12:39
|
|
|
I'm currently working with a repository that has the following structure: ProjectName - Applications -- ProjectName (AGAIN!) --- trunk --- branches --- tags - Databases -- MyDBName --- trunk --- branches --- tags I assume this structure was created so that developers could add multiple applications to this repository under the Applications folder. I may be wrong, but this seems incorrect. Everywhere else I've worked, each project had its own repository. Additionally, being that databases is a different folder than applications, you can't associate a DB with a certain application. What I would like to do is take the --ProjectName repository out and create a whole new repository for that. But, I would like to keep all of the history for that give folder. Can I do this easily? I'm using VisualSVN. magic_toaster fucked around with this message at 17:00 on Dec 22, 2010 |
|
#
?
Dec 22, 2010 16:56
|
|
|
magic_toaster posted:I may be wrong, but this seems incorrect. One of the projects I'm working with right now is in a repository with 50 other projects. There's nothing wrong with that. magic_toaster posted:Additionally, being that databases is a different folder than applications, you can't associate a DB with a certain application. Why should application and database be a one to one correspondence?
|
|
#
?
Dec 22, 2010 17:50
|
|
|
danishcake posted:Can anyone recommend an issue tracker that can be used in a distributed fashion? Ideally I want something with minimal dependencies along the lines of TiddlyWiki, but tailored to issue tracking, and able to cope with a little light merging. Installing Python etc is not an option, but I do at least have access to a modern browser. If you want something a little more heavyweight you can use Fossil, assuming you're allowed to install it.
|
|
#
?
Dec 22, 2010 18:36
|
|
|
This is probably a really understood concept but I can't seem to grasp it. What if you have two branches say... branch1 and branch2 off of master. What if someone edits say... myfile.txt in both branches, and you merge in branch1. Now you can't merge in branch2 because it also edited the file?
|
|
#
?
Dec 23, 2010 12:25
|
|
|
You'll get a conflict that the algorithm can't resolve automatically. Instead it'll present you with both changes and ask you which one you want.
|
|
#
?
Dec 23, 2010 14:06
|
|
|
Unless the change is different enough, say one edit to line 1 and the other edit to line 20. Then it can usually merge them.
|
|
#
?
Dec 23, 2010 19:04
|
|
|
Hey guys I'm currently evaluating moving from SVN to something that handles renaming across different branches in a more intelligent manner. I want it to be able to branch from trunk, and in my branch I want to rename a file. If then have to make a change on trunk to that file, when I do a merge I want it resolve it automatically if it can or at least ask me to merge them. I don't want it to tell me that there is a tree conflict and have to do a merge by hand. It also needs to handle the case where I moved the file to another place in the directory hierarchy. I'm leaning more towards mercurial, but this feature is a must and I'll switch to anything else that can make these kinds of refactoring less painful.
|
|
#
?
Dec 23, 2010 19:54
|
|
|
Zhentar posted:One of the projects I'm working with right now is in a repository with 50 other projects. There's nothing wrong with that.
|
|
#
?
Dec 23, 2010 20:30
|
|
|
MEAT TREAT posted:I'm leaning more towards mercurial, but this feature is a must and I'll switch to anything else that can make these kinds of refactoring less painful. I think Mercurial should handle your case, at least if you rename the file using mercurial, i.e. code:
|
|
#
?
Dec 24, 2010 11:13
|
|
|
Can anyone suggest a method for perforce users (non-admin) to setup a review based on users and/or workspaces, rather than on specific files? What I'd like to do is allow people in my department to sign up to get email notifications on changelists done by people in their scrums , allowing them to keep on top of changes that will affect their work and may need further review or testing. I'd prefer to allow the list of names to review to be user definable based on username/workspace, in order to keep the amount of admin time needed down, but working with perforce groups would also probably be fine. Unfortunately, the only built in means of doing this seem to be having people setup a review on every source file we have, coupled with some rules in outlook that delete any changelist emails that are not based on submissions from people X, Y or Z. That solution isn't very clean, and this seems like something that should be a solved problem, but nothing seems to come up with a search of google or the P4 documentation.
|
|
#
?
Jan 12, 2011 05:18
|
|
|
More SVN woes, I have a working copy that isn't updating properly. The "last commit revision" property updates to the current repository revision number, or to the one specified in the update command, but no changes are applied. I committed a file yesterday and when I try to update it on this machine it remains the same, but SVN says it's current. At the same time, if a file is deleted it will be restored in the update. What's going on? Is there anything I should try before checking out again? Edit: nevermind, it was pointed at a branch. BizarroAzrael fucked around with this message at 15:54 on Jan 12, 2011 |
|
#
?
Jan 12, 2011 11:59
|
|
|
pre:4.0.0 4.1.0 4.2.0 4.3.0
--o----o----o----o----o----o----o----o----o----o--
\ /
\ 4.0.1 /
-----o---------------------------
I've merged a fix from an old release into the main line of development, which will be released as 4.3.0, that's all good. What about clients of mine that are in between, running 4.1.0 and 4.2.0? Don't they need the fix too, released as 4.1.1 and 4.2.1? I'm not sure how I can merge the fix into both the main line of development, AND intermediate minor builds. We're using mercurial. Is this what mercurial's "branches" are for? epswing fucked around with this message at 20:32 on Jan 12, 2011 |
|
#
?
Jan 12, 2011 20:18
|
|
|
epswing posted:We're using mercurial. Is this what mercurial's "branches" are for? Not an Hg user but this is not really specific to any one VCS: yes, you want branches, for this very reason. The typical setup I see is having a release branch for each "line" of development, and then some number of "developing the new hotness" branch(es) (which varies a lot but that's mostly orthogonal to this). So in your case, at this point in time, you "should" have had a branch each for 4.0, 4.1, and 4.2. Then you would've applied your fix to the 4.0 branch and tagged 4.0.1 to distribute to anybody using 4.0, and repeated that process by re-applying that patch to 4.1 and 4.2, and cutting 4.1.1 and 4.2.1 as you mentioned. And of course, applied it to the branch you're using for what will become the 4.3 line of development. The benefit of this kind of approach is hopefully obvious: you have independent clones of your source tree, branched off at the point in time where they were released, available for additional commits as you write or backport bugfixes. Tags alone are not usually sufficient for this as they typically just point to one single snapshot in time (as you've noticed).
|
|
#
?
Jan 12, 2011 22:03
|
|
|
bitprophet posted:re-applying that patch to 4.1 and 4.2 This right here is the missing link in my brain, how do I do this? Actually it might become clear after I finish reading about branches.
|
|
#
?
Jan 12, 2011 22:32
|
|
|
epswing posted:
iOS Developer Spotted.
|
|
#
?
Jan 12, 2011 22:49
|
|
|
epswing posted:This right here is the missing link in my brain, how do I do this? There's two angles to this: how to determine what changes to make to each branch to fix "the problem", and how to actually apply those changes. Usually you're lucky and the chunk of code you fixed the bug in has not changed a lot, or at all, from 4.0 to 4.3. In that case, you can just take the same literal change (i.e. you could make a diff/patch file out of it) and "apply" it to each branch as a separate commit. Manually that would be "check out 4.0 branch, edit file X with the change, then check out 4.1, edit file X with the change, [repeat for other branches]". VCSs often have tools to make this easier, Git lets you "cherry-pick" a commit from one branch and apply it to another one with one command -- I bet Mercurial can too. If you're not lucky, the code has changed such that the fix to 4.0 doesn't apply cleanly to later versions, and so what it means to "fix the problem" might be different -- only you can figure out what changes have to be made. Maybe your function got refactored so you have to go hunt down where those two lines that have the bug, ended up. Whatever. The mechanical process is the same: check out one branch, make the change, commit; check out the next branch, make maybe a different change to the same effect, commit; repeat. Once you're done with all this crap you've got one new shiny bugfix commit in each release branch, each saying something like "Fix bug #123", or maybe "Ported fix for #123 from the 4.0 branch". And now you can throw 4.1.1 at somebody and it has the fix. The entire point is to separate your released versions so you can apply changes to them independently of one another.
|
|
#
?
Jan 13, 2011 00:07
|
|
|
mercurial transplant == git cherry-pick
|
|
#
?
Jan 13, 2011 02:54
|
|
|
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
|
|
|
uXs posted:Nothing is stopping you from merging 4.0.1 with 4.1.0, and releasing that as 4.1.1. While I'm here, here's a question I've wondered about Github: is there a conscious decision around why they don't have a tree graph (or DAG or swim-lane graph or whatever you call it)? Bitbucket has this on their commits page, as do a lot of Git log viewers (including git log --graph). Magicmat fucked around with this message at 13:34 on Jan 18, 2011 |
|
#
?
Jan 18, 2011 13:31
|
|
|
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
|
|
|
|
| # ? May 10, 2024 09:16 |
|
|
There's nothing scary about fast-forward merges, it's just the simple observation that when you merge A <- B <- C <- D <- E into A <- B <- C, you don't actually have to do any work.
|
|
#
?
Jan 19, 2011 07:17
|
|
