|
Belgarath posted:I have to use Sourcesafe at work (I know, but it's out of my hands), but I've started using Git for my personal stuff. I was wondering if I could use Git at work, so that I could init a Git repo in my sourcesafe checkout, do some work, make some branches in Git, and then check back into sourcesafe after merging my Git branches into master? Knowing next to nothing about Sourcesafe and Clearcase, if you set both systems to ignore each other (SS/CS ignore .gitignore and .git/ and so on and vice versa), I don't see why not.
|
# ? Sep 10, 2009 14:48 |
|
|
# ? May 16, 2024 18:39 |
|
I think the bigger problem you'll have to deal with, vis-a-vis sourcesafe, is the whole making files readonly/locking stuff nightmare.
|
# ? Sep 10, 2009 19:18 |
|
Posting to say that I'm now using git with a google code svn repository and it's working awesomely. The easy branches thing is pretty cool, too. Running it inside a VM on windows, too.
|
# ? Sep 10, 2009 20:21 |
|
BizarroAzrael posted:The master script, which calls all the other scripts to perform the update, is to be versioned as Update.bat.template, so users will need to cut off the ".template" and unversion it for it to work. Doing this for the other scripts seems impractical though, I don't want users having to muck around with them themselves. I thought about having them versioned as .templates as well, and having the master script rename them. Would it work to have the script rename them all by removing the .template? Then the update would restore the original .bat.template files which would be used next time the update runs. We did pretty much the same thing at the last place I was at, except putting it in a directory rather than renaming files from .template. It made things a bit easier since you had a working file if you were working with the source controlled version (especially useful because we had a series of files which referenced each other), and you could run the update script from any directory. Later on down the road our update got quite a bit more complex, so the .bat file ended up being a bit of a loader script that only updated the main updater tool and then executed it (by that point it was actually a winforms app). That was probably the least painful, as you didn't have the "double-update" whenever you updated the updater.
|
# ? Sep 11, 2009 14:28 |
|
I have a question about version numbers as they relate to version control. At the company where I recently worked, the version number of a software package was stored in a file that's part of the project. The checked-in version number string usually ended in "-dev", like "1.4.0-dev", for development builds of the software. Release candidates had version strings like "1.4.0-rc3". The company made hardware devices as well as the software to run them, so it was common for developers to test changes by loading their development builds on real hardware. The test department could tell at a glance that a system was running a development version of software, and bring issues to the attention of the developer who made it instead of entering it in the issue tracker. Whenever the lead developer tagged a release candidate or released version, he/she would do so by modifying the version number string, committing that file, tagging the software at that state, and then restoring and committing the "-dev" suffix. It's this last part of the process that I think is a little clumsy and I'm wondering how to improve it. For a personal project, I can tell that (for example) the binary in my project directory reports "v2.4.10" but it's actually "v2.4.10 plus changes that I'm still working on". It isn't nearly as important to have the "-dev" suffix for development builds of a personal project, but I got used to that process and I quite like it. How would you handle this? I'm using Git, and I considered always having the version number as "-dev" in the master branch, then tagging a release by making a branchless commit that changes the version number. For example: code:
Should I care about this at all? It's really only useful to get information about a binary that I didn't produce and am not familiar with. I don't keep old binaries around (that's what version control is for) and I'm the only one working on this project, so this is probably a moot point.
|
# ? Sep 12, 2009 03:04 |
|
wwb posted:I think the bigger problem you'll have to deal with, vis-a-vis sourcesafe, is the whole making files readonly/locking stuff nightmare. The Sourcesafe integration with Visual Studio handles all that at the moment (when you edit the file, it checks it out and makes it writeable, vice-versa on check-in), although as you say, it is a concern of mine that once I break that link, things could go a little haywire. I'm not sure if Visual Studio will make a file writeable that it doesn't think is under version control.
|
# ? Sep 12, 2009 17:05 |
|
Belgarath posted:The Sourcesafe integration with Visual Studio handles all that at the moment (when you edit the file, it checks it out and makes it writeable, vice-versa on check-in), although as you say, it is a concern of mine that once I break that link, things could go a little haywire. I'm not sure if Visual Studio will make a file writeable that it doesn't think is under version control. You might want to setup 2 IDE projects for this, 1 hooked into VSS and 1 where you'll manage things on your own. You can use the VSS one to do small changes and checkin/checkout via the IDE. When you want to get git involved, do a manual checkout on all of the files involved via the standalone VSS client, create your git repositories, then use that 2nd IDE project. When you're done, push the completed files from your git repo back to your VSS working dir and checking via the VSS client. That said, I think this is a pretty crazy idea. You're probably going to run into issues when you start moving and renaming files, 2 things which VSS is notoriously bad at. You also need the foreknowledge of which files you want to checkout from VSS before you start working on your feature. Once the scope expands, you may find you need a file that someone else is already working on.
|
# ? Sep 12, 2009 23:37 |
|
Wow, Google Code has had Mercurial support since the end of April: http://googlecode.blogspot.com/2009/04/mercurial-support-for-project-hosting.html I know I'm late to the party but it caught me by surprise. I'm probably not the only one who didn't know. I wish they supported Git but it's cool to see them supporting any DVCS.
|
# ? Sep 13, 2009 07:24 |
|
samiamwork posted:Wow, Google Code has had Mercurial support since the end of April: They ripped out Mercurial's native storage implementation and made it a wrapper around BigTable, which isn't something you can easily do with git.
|
# ? Sep 15, 2009 00:43 |
|
pseudorandom name posted:They ripped out Mercurial's native storage implementation and made it a wrapper around BigTable, which isn't something you can easily do with git. I wonder if hg-git would do the trick. I've never had a reason to try it though. Edit: I actually read the hg-git page again, and saw this is the exact opposite of what you'd need. Whoops
|
# ? Sep 15, 2009 00:45 |
|
pseudorandom name posted:They ripped out Mercurial's native storage implementation and made it a wrapper around BigTable, which isn't something you can easily do with git. I had read through their analysis (http://code.google.com/p/support/wiki/DVCSAnalysis) and I totally understood why they went with Mercurial over Git. I'm not saying they *should* have gone with Git, just that I wish they had gone with Git since I like both Git and Google Code. Strangely enough they didn't seem to think porting the file store to BigTable was any harder with either.
|
# ? Sep 15, 2009 03:22 |
|
samiamwork posted:I had read through their analysis (http://code.google.com/p/support/wiki/DVCSAnalysis) and I totally understood why they went with Mercurial over Git. I'm not saying they *should* have gone with Git, just that I wish they had gone with Git since I like both Git and Google Code. Despite it's tendency to get bogged down from time to time, I actually prefer GitHub over Google Code personally. It targets more of the atmosphere I would like from a public code repository than Google Code does.
|
# ? Sep 15, 2009 04:01 |
|
Ferg posted:Despite it's tendency to get bogged down from time to time, I actually prefer GitHub over Google Code personally. It targets more of the atmosphere I would like from a public code repository than Google Code does. Yeah, GitHub is pretty awesome. I just wish they would stop using so much Flash on their site (actually I wish they would stop using Flash completely). For me, the big thing Google Code has going for it is that it's Google and it's safe to say they're not really going anywhere. I'm not so sure about GitHub yet, but who knows SourceForge is still around and I have no idea what keeps them afloat.
|
# ? Sep 15, 2009 06:10 |
|
samiamwork posted:Yeah, GitHub is pretty awesome. I just wish they would stop using so much Flash on their site (actually I wish they would stop using Flash completely). For me, the big thing Google Code has going for it is that it's Google and it's safe to say they're not really going anywhere. I'm not so sure about GitHub yet, but who knows SourceForge is still around and I have no idea what keeps them afloat. If Google Code had git I'd be happy as hell. Anywho, I'm having a bit of an issue with git, basically every time something gets pulled from a repo, git resets the permissions to rwxr--r-- which sucks, because the group (users) needs to be able to work on the files. Why is this happening? How can I stop it? Thanks
|
# ? Sep 15, 2009 15:46 |
|
haywire posted:Anywho, I'm having a bit of an issue with git, basically every time something gets pulled from a repo, git resets the permissions to rwxr--r-- which sucks, because the group (users) needs to be able to work on the files. Why is this happening? How can I stop it? Unfortunately this is due to a core aspect of how Git does its thing -- it cares primarily about chunks of text and not so much about the actual files/directories on disk. A relatively decent answer I found googling around was actually here on StackOverflow. Kind of surprised they don't address this in the official Git FAQ; perhaps I was searching for the wrong phrases or something vv Anyway, if it's happening on every pull, that strikes me as a tad odd -- I don't recall having that issue myself. Assuming it's happening due to files being newly created somehow, you could try working around it by setting your umask to something more permissive (e.g. 0002), or seeing if setting the setgid bit on the top level directory helps any (which should mean that new files created get that directory's group-ownership.)
|
# ? Sep 15, 2009 16:32 |
|
If there a good way to find conflicting files in a working copy without attempting an update on it? We have guys that often get conflicts and it would be nice if I could scripts something that finds the problems so they can be fixed by hands, rather than have them kill the overnight update and the subsequent build process.
|
# ? Sep 18, 2009 14:56 |
|
BizarroAzrael posted:If there a good way to find conflicting files in a working copy without attempting an update on it? We have guys that often get conflicts and it would be nice if I could scripts something that finds the problems so they can be fixed by hands, rather than have them kill the overnight update and the subsequent build process. You could maybe do a 'svn diff BASE:HEAD file-in-working-copy' for each remotely updated file, but you'd basically be reimplementing (or wrapping) patch to determine whether it can cleanly apply the diff. I have a more general question for you, though: do I understand correctly that this nightly update/build happens on each developer's machine? Why? Is it so hard to do a manual svn update whenever there are changes that you think you should have? Does the build of your project take several hours or something? I'm just curious. EDIT: Free Bees is right; I meant svn status instead of svn update. Lysidas fucked around with this message at 06:58 on Sep 19, 2009 |
# ? Sep 18, 2009 19:41 |
|
haywire posted:If Google Code had git I'd be happy as hell. Why are multiple people working on the same repository?
|
# ? Sep 18, 2009 22:26 |
|
floWenoL posted:Why are multiple people working on the same repository? Checkout on a staging or production server, maybe? That's where I run into SVN multiuser permissions issues, anyway. Person A checks repo out, now person B can't run an svn up to deploy on a day when Person A is out of the office or whatever. Granted, we don't "work on" the files in this situation (that's a huge no-no) but the problem is the same.
|
# ? Sep 19, 2009 03:06 |
|
BizarroAzrael posted:If there a good way to find conflicting files in a working copy without attempting an update on it? We have guys that often get conflicts and it would be nice if I could scripts something that finds the problems so they can be fixed by hands, rather than have them kill the overnight update and the subsequent build process. svn status -u
|
# ? Sep 19, 2009 06:49 |
|
Just found gource and had to share. If you've got a few minutes, download this and point it at your git repository. Hypnotic AND informative
|
# ? Sep 23, 2009 22:36 |
|
haywire posted:Anywho, I'm having a bit of an issue with git, basically every time something gets pulled from a repo, git resets the permissions to rwxr--r-- which sucks, because the group (users) needs to be able to work on the files. Why is this happening? How can I stop it? Edit: Apparently I'm wrong and that only applies to the files in the repository itself. Oh well. welcome to hell fucked around with this message at 09:25 on Sep 25, 2009 |
# ? Sep 25, 2009 08:46 |
|
floWenoL posted:Why are multiple people working on the same repository? Because the website is giant and most of the time we need to make small changes that don't require having a copy of several GB site and db on our own boxes. I know it is an un-ideal situation, but I really can't think of a better solution at the moment.The site is some giant hack of a 2003 version of osCommerce, I'm pushing for a rewrite, but there's just so much functionality we'd have to replicate. Haarg posted:The permissions used for files in working copy can be controlled with the core.sharedRepository config option. It can be set to group, all, umask, or a mode in octal. The default is to use the umask. It's documented in the git config documentation. Hey, I may try that - it is mainly the repo files (the ones under .git/ that are the issue, now.). Thanks!
|
# ? Sep 25, 2009 09:45 |
|
If I do an update to the head revision, is there some way to capture the specific revision number for later use? I would like for my update script to be able to make sure it's not going to "update" to an old version. Basically check a record of yesterday's revision against the current one, do the update and record the new revision number for tomorrow. Edit: I think I have it, I can issue an SVN info command and have the output written to a file, then grab the current version number from it. Kind of embarrassed I didn't think of it sooner. BizarroAzrael fucked around with this message at 15:10 on Sep 29, 2009 |
# ? Sep 29, 2009 10:36 |
|
As mentioned up the page I'm currently using git. I've made a new branch of the website (specifically python/django) to work on some new features and I've made a new directory in the site called "tasks/" on the "tasks" branch. The problem comes when I checkout the "master" branch again and the "tasks/" directory is still there in the file system. I've set git up to ignore .pyc files, since they're just compilation objects and I don't want them hanging around, but doing this means that they're still hanging around and propping up the old directory structure. Shall I add them? Will it pollute the svn repository when I push the changes back up?
|
# ? Sep 30, 2009 11:39 |
|
chips posted:The problem comes when I checkout the "master" branch again and the "tasks/" directory is still there in the file system. I've set git up to ignore .pyc files, since they're just compilation objects and I don't want them hanging around, but doing this means that they're still hanging around and propping up the old directory structure. Shall I add them? Will it pollute the svn repository when I push the changes back up? Is your problem that the directory exists, period, or is it that it's showing up in your git status output when in the master branch? As you mentioned, the latter can be fixed by ignoring it: you can create a top level .gitignore file, which is itself versioned, and thus can differ between branches. The former can be "fixed" by running git clean (which has options, read up on 'em, you'll probably need to do e.g. git clean -fd) but I can't recall offhand if you'd need to do that every time you checkout master, or if there's a shortcut for it, or what.
|
# ? Sep 30, 2009 17:41 |
|
bitprophet posted:Is your problem that the directory exists, period, or is it that it's showing up in your git status output when in the master branch? I use git clean -x -f -d for handling cleanup of cross directory stuff. I also have a rmpycs alias available to me at all times.
|
# ? Sep 30, 2009 18:28 |
|
Okay, back to my recurring problem with conflicts in SVN. If a guy has an unversioned file in the project, and someone commits a file by the same name, the resulting conflict kills the update. Updates can take over an hour so it's done at night, and is followed by a build on the resources within, so this leads to a lot of lost time. The best I can think of to solve this is to do an SVN status on the whole project, outputting to a text file, pick out all the unversioned files using a script, back them up elsewhere and copy them back after the update. The end result for files that would be conflicted is that they remain the same but are now versioned and marked as locally changed, as far as I can see. This really isn't elegant though. Everyone keeps unversioned files that they will never commit. Can anyone propose a way to find only the files that are about to be conflicted and fix them so they remain the same and become versioned, or maybe renamed to filename.txt(1) or something?
|
# ? Oct 7, 2009 18:01 |
|
BizarroAzrael posted:Okay, back to my recurring problem with conflicts in SVN. If a guy has an unversioned file in the project, and someone commits a file by the same name, the resulting conflict kills the update. Updates can take over an hour so it's done at night, and is followed by a build on the resources within, so this leads to a lot of lost time. Maybe I misunderstand the problem, but if you don't want the files in source control it's usually a good idea to use svn:ignore.
|
# ? Oct 8, 2009 00:44 |
|
There is a function that I edited a few commits ago that is no longer working. How do I checkout an older version of a file from, say, 4 commits ago? I don't want to undo anything, I just want to mess around with an older version to do some debugging. I'm using git...
|
# ? Oct 8, 2009 09:29 |
|
Dromio posted:Maybe I misunderstand the problem, but if you don't want the files in source control it's usually a good idea to use svn:ignore. No, I don't want to keep the file out of version control, and I want the versioned copy to be received by, or at least available to, everyone. Having an ignore stopping the versioned copy being recieved could stop something critical being received, and would need to be done manual by users, possibly for many files. Actually, I'm not quite sure how SVN will behave if someone commits a file with the same location and name as one that is ignored on another local copy which updates. BizarroAzrael fucked around with this message at 10:23 on Oct 8, 2009 |
# ? Oct 8, 2009 09:45 |
|
So then why are you going out of your way to not version local copies of versioned files? What do you mean someone has an unversioned file "in the project"? In their own working copy?
|
# ? Oct 8, 2009 10:17 |
|
nbv4 posted:There is a function that I edited a few commits ago that is no longer working. How do I checkout an older version of a file from, say, 4 commits ago? I don't want to undo anything, I just want to mess around with an older version to do some debugging. I'm using git... git checkout HEAD~4 path/to/my.file
|
# ? Oct 8, 2009 10:59 |
|
Doc Block posted:So then why are you going out of your way to not version local copies of versioned files? Example I've been given is that someone moves a new file to a build machine for testing, so the conflict occurs after committing it on either machine if it's not removed from the other. Though I believe we have also had people separately create files in the same location and name and create a conflict when one commits it. I'm trying to make a script that will use SVN diff to get a list of files committed between the last update and the new one, but I have checked and found that some of the files added between the version number I give it are left out. Can anyone explain this? Edit: SVN log -v -r [version]:[version] looks hopeful. BizarroAzrael fucked around with this message at 16:46 on Oct 8, 2009 |
# ? Oct 8, 2009 16:36 |
|
Can't you run a soft update and get the list of files that way? Also why do you want automated builds to run flawlessly on uncontrolled environments? If people are polluting the checkouts, cleanliness isn't something you can guarantee, right? Or you want a workflow that's equivalent to making a fresh checkout and then applying a local modification atop it and trying to build that, but without the cost of an entire checkout?
|
# ? Oct 8, 2009 16:49 |
|
Triple Tech posted:Can't you run a soft update and get the list of files that way? As far as I know, you can only get a lsit of files like that through tortoise, not the command line level I need to make scripts for. A lot of people require an up-to-date build very frequently. It is possible to apply a local change and do a partial rebuild to implement it in the local copy, but that requires a complete build to have been done if you don't want to build the whole thing. We want an update a build run every night with local changes preserved. If local changes result in a bugged build they can either be reverted or the backup can be used later.
|
# ? Oct 8, 2009 17:56 |
|
Does anybody know how exactly a git graph is built out? I figured it'd be a fun project to build a graphing tool, something to compliment a git tool I've already built, but I can't seem to find any information that really explains the concept behind it, at the lowest possible level within git.
|
# ? Oct 15, 2009 22:27 |
|
Ferg posted:Does anybody know how exactly a git graph is built out? I figured it'd be a fun project to build a graphing tool, something to compliment a git tool I've already built, but I can't seem to find any information that really explains the concept behind it, at the lowest possible level within git. Don't most of the various tools print out parent and child SHAs all over the place? or is that not what you're looking for?
|
# ? Oct 16, 2009 00:03 |
|
bitprophet posted:Don't most of the various tools print out parent and child SHAs all over the place? or is that not what you're looking for? How will you know when a fork/merge occurred though and when?
|
# ? Oct 16, 2009 00:35 |
|
|
# ? May 16, 2024 18:39 |
|
Ferg posted:How will you know when a fork/merge occurred though and when? If a changeset has more than one child, new branches have been created. If a changeset has more than one parent, a merge has occurred. http://eagain.net/articles/git-for-computer-scientists/ http://git.kernel.org/?p=git/git.git;a=blob;f=graph.c;h=6746d422a98ed010489d4ce74b26a8a4600b183e;hb=HEAD This might be easier to read than graph.c, and Mercurial's history model is essentially the same as Git's: http://selenic.com/repo/hg/file/17da88da1abd/hgext/graphlog.py
|
# ? Oct 16, 2009 01:05 |