|
nelson posted:So if your source files are ASCII text files and you or the people you work with are like me 1. This is awful advice 2. Even if you're a SCM-trashing moron, SCM does not preclude backups (well, you can make an argument for some DVCS systems...). Back your source control repositories up regularly!
|
#
?
Jan 16, 2010 18:17
|
|
you may want to go with CVS.
|
|
| # ? May 3, 2024 14:18 |
|
|
Lysidas posted:What the hell is wrong with you? How did you manage to break a Subversion repository unless you were trying to do it on purpose? Did you try to directly edit the repository files, or something? 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.
|
|
#
?
Jan 16, 2010 18:39
|
|
|
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. How did that break the repository and not just the local working copy? If you messed up the local working copy that badly, just delete it, or copy the files without the .svn directories. Pretty sure loving up a subversion repository is pretty hard to do.
|
|
#
?
Jan 16, 2010 19:13
|
|
|
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. svn help export Learn to use your tools. EDIT: though I will agree, .svn directories suck.
|
|
#
?
Jan 16, 2010 19:29
|
|
|
nelson posted:CVS is generally better than RCS for group work nelson posted:I've managed to screw something up every VCS I've come in contact with Never use CVS for a new project, and never use it at all if you can avoid it.
|
|
#
?
Jan 16, 2010 19:47
|
|
.
|
Lysidas posted:As far as I know, RCS has no group/multi-user capabilities at all. Using RCS for group work seems difficult. Isn't that why CVS exists? IIRC, RCS is somewhat capable of multiuser using a shared file system, but RCS works on an exclusive checkout + lock model, which is an utter pain, as you have to checkout and lock a file to remove write-protect and make changes. CVS is a hack on top of RCS that added network stuff and removed exclusivity, making it indeed much better for groups... And SVN is of course CVS done right, and is much better in virtually every way....
|
|
#
?
Jan 16, 2010 20:00
|
|
|
Chlamydia: syphilis done right
|
|
#
?
Jan 16, 2010 20:21
|
|
|
musclecoder posted:Pretty sure loving up a subversion repository is pretty hard to do. You can do pretty easily it if you have a group of people using a single repo shared over a network, or at least you could. I suppose it's possible they changed that. Otto Skorzeny posted:Chlamydia: syphilis done right Well, if you have to pick between the two, you go with the chlamydia. Munkeymon fucked around with this message at 17:10 on Jan 19, 2010 |
|
#
?
Jan 19, 2010 17:04
|
|
|
Munkeymon posted:You can do pretty easily it if you have a group of people using a single repo shared over a network, or at least you could. I suppose it's possible they changed that. I think you're referring to a working copy. If you have several people working on the same shared copy over a network, you're doing source control wrong. If you actually mean you have several people working on the same repository over a network, thats how its supposed to work.
|
|
#
?
Jan 19, 2010 17:10
|
|
|
musclecoder posted:I think you're referring to a working copy. If you have several people working on the same shared copy over a network, you're doing source control wrong. At the place I used to work we had a repo on a network share that we all used that got a little buggy on us because the database wasn't able to use the filesystem read/write locking over the share. I fixed it by setting up the SVN server and having everyone use that.
|
|
#
?
Jan 19, 2010 17:15
|
|
|
I've googled for hours and couldn't find anything. I use SVN and I was looking for a simple pre|post-commit hook script that would get all the data from the commit (author, date, comment, affected files, etc.) and would POST it as XML, Json, whatever to a predefined URL. Anyone know of such a thing? My svn server is on linux, and I have shell access.
|
|
#
?
Jan 21, 2010 05:02
|
|
|
Sefyroth posted:I've googled for hours and couldn't find anything. The integration script for CIA.vc (a site that tracks commits to various OSS projects) has XML-RPC hooks; and may be tweakable for your nees. See: http://cia.vc/clients/svn/ciabot_svn.py
|
|
#
?
Jan 21, 2010 05:36
|
|
|
Sefyroth posted:I've googled for hours and couldn't find anything. This isn't exactly what you're looking for, but may put you in the right direction. I wrote a few articles a while ago about pre/post commit hooks in SVN: http://leftnode.com/subversion-hooks-post-commit/ http://leftnode.com/subversion-hooks-pre-commit/ The post-commit parses a message for a bug ID and posts it to a mantis database, and the pre-commit lints all of the changed PHP files to ensure none of them syntactically break the build
|
|
#
?
Jan 21, 2010 11:38
|
|
|
This is probably really stupid, but I want to know if it's possible. I have a project that I'd been working on and storing in a git repository. About a month ago I decided to scrap everything and start over, and stored that project in a separate repository. Now, there's obviously no reason to keep both of them around, but I'd like to have the old project's history. Is there a way that I can sort of stitch them together, so that after the last commit on the original project, the new project begins? (And it would appear that all of the old files were deleted because the first commit of the new project was empty)
|
|
#
?
Jan 22, 2010 03:12
|
|
|
OddObserver posted:The integration script for CIA.vc (a site that tracks commits to various OSS projects) has XML-RPC hooks; and may be tweakable for your nees. See: I love you so much. I just changed the part where it used xml-rpc to the server and made urlib2.urlopen("myurl", message) and all is well! The data it generates is pretty nifty too. Edit: Really, really nice. Finally got my Gemini set up with my SVN server! Thanks again. Sefyroth fucked around with this message at 05:06 on Jan 22, 2010 |
|
#
?
Jan 22, 2010 04:21
|
|
|
Lamont Cranston posted:This is probably really stupid, but I want to know if it's possible. I have a project that I'd been working on and storing in a git repository. About a month ago I decided to scrap everything and start over, and stored that project in a separate repository. Now, there's obviously no reason to keep both of them around, but I'd like to have the old project's history. Is there a way that I can sort of stitch them together, so that after the last commit on the original project, the new project begins? (And it would appear that all of the old files were deleted because the first commit of the new project was empty) This is certainly possible, and not stupid. It's called a "graft", in Git terminology. See http://git.wiki.kernel.org/index.php/GraftPoint This is a temporary mechanism that adds a fake parent to whatever commits you want. You can make it permanent by running git filter-branch after setting up a graft point. I'm not quite sure what the filter-branch arguments should be for this, but I'm sure it's somewhere on http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html EDIT: Be warned that git filter-branch rewrites history in bulk, changing the SHA-1 values of all commits downstream from where you grafted onto the old history. People won't like this if you've shared your history and they've based their work on yours. EDIT 2: Actually it's quite easy: code:Lysidas fucked around with this message at 05:26 on Jan 22, 2010 |
|
#
?
Jan 22, 2010 05:08
|
|
|
Lysidas posted:This worked perfectly. Thanks!
|
|
#
?
Jan 22, 2010 18:54
|
|
|
I'm learning to program ObjC/Cocoa and I still do some web design, though mostly for myself. Even though I'm working alone, I want to put all of it under version control (not only for peace of mind, but because it's just a good habit to get into). In the past, I usually just used snapshots of folders and burned discs. So here are my questions: 1) I have Subversion on my MacBook Pro and I'm looking at Versions.app (a front-end to SVN), but it seems like the one developers really seem to love these days is Git. Should I use Git or is SVN fine? 2) Since I'm going to be doing web development, too, how do VC stystems handle images? Will SVN/Git hold full copies of images/PSDs, or will it just store the deltas (which would screw up binary files like JPGs, PNGs or PSDs)? What are people's thoughts on images in version control systems?
|
|
#
?
Jan 25, 2010 21:03
|
|
|
stray posted:I'm learning to program ObjC/Cocoa and I still do some web design, though mostly for myself. Even though I'm working alone, I want to put all of it under version control (not only for peace of mind, but because it's just a good habit to get into). In the past, I usually just used snapshots of folders and burned discs. 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. Some VCSs store binary files in full, others use deltas. Deltas won't "screw up" files, but whether they save space will depend on the formats you're storing. For example, PNG or JPEG files will usually not see much advantage from deltas. I don't know enough about PSD to comment on it.
|
|
#
?
Jan 25, 2010 23:11
|
|
|
I just spent an hour and a half using hg-git and git's post-receive hook to let me push to hg-git's internal git repository and automatically have that do hg-git's pull and then hg-push the changes to our central mercurial repository! Now I can pretend that mercurial does not even exist and just use git! At least until someone else pushes something into the repository and I get conflicts. 
|
|
#
?
Jan 26, 2010 04:53
|
|
|
Vanadium posted:I just spent an hour and a half using hg-git and git's post-receive hook to let me push to hg-git's internal git repository and automatically have that do hg-git's pull and then hg-push the changes to our central mercurial repository! Now I can pretend that mercurial does not even exist and just use git! At least until someone else pushes something into the repository and I get conflicts. That's pretty neat, and I like git and all, but what's wrong with just using mercurial if that's what the rest of the team uses? They seem pretty similar, feature-wise.
|
|
#
?
Jan 26, 2010 17:44
|
|
|
It is a hobby thing that I was only going to contribute to sporadically and I kind of wanted to avoid spending half of the time trying to figure out how hg is different from git. In retrospect, that was pretty silly.
|
|
#
?
Jan 26, 2010 17:51
|
|
|
Someone seems to have had a hiccup after merging back to the SVN trunk version after previously being on a branch, so now some portions of their working copy are still on the branch. Can anyone suggest how best to deal with this? Apparently it's caused by a bug in the Switch function.
|
|
#
?
Jan 28, 2010 17:05
|
|
|
edit: I am an idiot. I should read before replying with the same thing.
tef fucked around with this message at 23:13 on Jan 28, 2010 |
|
#
?
Jan 28, 2010 23:08
|
|
|
mr_jim posted:That's pretty neat, and I like git and all, but what's wrong with just using mercurial if that's what the rest of the team uses? They seem pretty similar, feature-wise. Nothing's wrong with hg, git just has some really killer features that make it a lot nicer to use once you get the hang of it. The index/staging area http://plasmasturm.org/log/gitidxpraise/ and the pile of ways that git makes screwing around with your repo history easy, for example.
|
|
#
?
Jan 30, 2010 05:54
|
|
|
Karanth posted:Nothing's wrong with hg, git just has some really killer features that make it a lot nicer to use once you get the hang of it. The index/staging area http://plasmasturm.org/log/gitidxpraise/ and the pile of ways that git makes screwing around with your repo history easy, for example. If you primarily use that staging area to make partial commits, well, hg can do partial commits too. I do it all the time.
|
|
#
?
Jan 30, 2010 12:33
|
|
|
uXs posted:If you primarily use that staging area to make partial commits, well, hg can do partial commits too. I do it all the time. Wow, I used hg for a year and a half both at work and on personal projects and I never knew about the record extension. Thanks! If I find myself using it again that will definitely come in handy.  It's a big plus to the staging area, yes. But I also like the way that it lets you build commits in pieces as you go, sometimes using different tools along the way. That's just the index, without even getting into differences in how the two tools handle branching. Git seems to promote the idea of cleaning up your history before making it public while hg seems to promote the idea that history is what it is, for better or for worse. Maybe that's more of a cultural difference than a technical one, but it always seemed a little off that most of the juicy commands for hg were hidden away in extensions you had to explicitly enable. Basically I can see why someone would spend an hour or so creating some bridge scripts so they can still use tools they're comfortable with.
|
|
#
?
Jan 31, 2010 20:13
|
|
|
Has anyone ever made C# apps to deal with SVN. I'm making something to deal with the above issue with part of a working copy being pointed at a branch. The idea is you run the app and it tells you what URL every directory is pointed at. Problem is that it wastes a lot of time trying to SVN info on unversioned directories or stuff in the .SVN folders. Is there a good, quick way that C# can determine if a directory is versioned or now?
|
|
#
?
Feb 2, 2010 16:44
|
|
|
I've used SharpSVN to interact directly with a repository as a client. I forget how well it works against an existing working copy, but I expect it should be fine.
|
|
#
?
Feb 3, 2010 16:03
|
|
|
What is the best free-as-in-beer CVS (not SCM) management tool? We've lately found ourselves in situation where removed source files are popping back in because of tags etc. and apparently our CVS repository is in dire need of management/cleaning. To be a bit more exact, we have legacy product which has previously been developed with the "pour everything into it" mentality. Generally HEAD of that project is unstable/doesn't compile/has all sorts of weird quirks and somewhere behind comes version specific tags which are used to promote parts of the software to new version. After that the sources have been branched from that tag version and possible bug fixes etc. are pushed into those branches which are never merged back to HEAD directly. Lately (as in during the last year and a half) we've realized that we actually like to manage our dependencies properly (Ivy!) and that instead of having everything in one huge product we could have a product core with dozen or so smaller libraries. This has lead to the following problem: Consider a source file developed over time in the way described above: It's different versions have different tags. Now, few of those source files are extracted to its own project and thus removed from HEAD. However since the tags still do exist the removed files creep back in through after deletion, because tagging new version from previous version is quite common: As said, HEAD is our experimental branch of sorts. Anyway, now we have "dead" files in the latest version tag and its branch with the new library project as dependency which causes conflicts and is a hell to manage. What I'd like to be able to do at least is to go through all the deleted files and either delete the tags from those removed files or move them to one revision before the removal (as far as I understand, CVS logs the removal as a new revision of the file). This should fix the issue we have right now. And yes, feel free to tell how horrible scheme this is, we know it ourselves too - the project is a legacy project and is older than Eclipse and the development started way before CVS was included in the whole source management process. Also we're looking into moving onto some DVCS, most likely Mercurial but that's in the future and we have this issue now.
|
|
#
?
Feb 4, 2010 16:42
|
|
|
Speaking of horrible schemes versus best practices, I like that Perforce has some whitepapers publicly available on the topic: http://www.perforce.com/perforce/papers/bestpractices.html 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.
|
|
#
?
Feb 4, 2010 17:11
|
|
|
What I found telling is that another group at my company switched from VSS or something else horrible to Perforce, but continued bad practices including the first thing one sees on the page above: * Don't share workspaces. (with other developers)
|
|
#
?
Feb 4, 2010 17:16
|
|
|
So has anyone encountered this problem SVN seems to have with switching sometimes that leaves a working copy sometimes partially pointed at the wrong branch/trunk? Is there a good way to easily detect this occurring and set it straight? Right now I'm trying to make a batch script that svn info queries each directory for their URL, but it seems to fall over without checking the whole working copy for some reason.
|
|
#
?
Feb 10, 2010 16:39
|
|
|
In our lab, I have been writing a large amount of code that is used by everyone and it has ended up in people having all different versions of my work which causes all sorts of compatibility issues. I would really like to implement some form of version control for myself, but then also have it so that I can "push" the newer versions onto the different client machines of the people who use my code. Some of them could possibly edit this code as well. Is this possible? If so, what should I be looking to use for this?
|
|
#
?
Feb 12, 2010 03:48
|
|
|
Modern Pragmatist posted:In our lab, I have been writing a large amount of code that is used by everyone and it has ended up in people having all different versions of my work which causes all sorts of compatibility issues. The obvious problem here is that if people make modifications to their local copy, then conflicts need to be merged somehow. I think a better way to do this would be to create a read-only NFS share (or whatever) which your users' machines mount on boot and have that directory added to the users' path (edit /etc/skel/ so new users get it etc.). Create a git (or whichever, really) repository somewhere that has a post-update hook to copy all of your tools to that network share. Encourage people not to make local copies of the files, but to improve them and push the changes back to the git repo so everyone gets the new features. I'm not a sysadmin or a Unix expert or a git superguru, but you get the idea.
|
|
#
?
Feb 12, 2010 04:49
|
|
|
Would you ever turn down a job because of the version control system they use? I'd like to imagine that this has happened at least once, somewhere:quote:(during interview/tour/whatever)
|
|
#
?
Feb 12, 2010 20:40
|
|
So what do you use for version control?
Visual SourceSafe, dictated by management.
|
Lysidas posted:Would you ever turn down a job because of the version control system they use? I'd like to imagine that this has happened at least once, somewhere: If management gives the impression that they always consider their first choices to be best, then the business probably has a load of other problems.
|
|
#
?
Feb 12, 2010 21:09
|
|
|
Anyone messed with Fossil at all? Sounds a bit interesting, especially for smaller/scattered projects.
|
|
#
?
Feb 13, 2010 01:19
|
|
|
Fly posted:It depends on how firm the management position is. Some shops just continue to use VSS because they started with it, and changing processes is disruptive. If one were committed to staying at the place, then eventually reasonable management should be open to well-reasoned proposals for change from respected team members. I think the choice of source control systems also says something about the culture of the development group. During my last interview the dev manager asked "What are your thoughts on source control?" and I replied "it's a requirement for any serious development team, I've used most major ones but prefer a distributed model like git/mercurial, blah blah". He looked at me blankly and then muttered that they didn't have anything in place yet. That was a very big negative in the interview-- It indicated to me just how lacking the dev team was in disciplined processes. I've also had multiple discussions with people who were so afraid of not having locked access to a file like VSS. "What if I work on something while Bill does?" Again, this is a good indicator that their code architecture is hurting and they haven't really paid attention to separation of concerns. So yeah, I think knowing something about a group's source control system is a HUGE indicator of what you're getting yourself into. It hasn't stopped me, but it prepared me for how much I'll have to work with the team on improving some aspects of their craft.
|
|
#
?
Feb 14, 2010 14:54
|
|
|
|
| # ? May 3, 2024 14:18 |
|
|
Dromio posted:I've also had multiple discussions with people who were so afraid of not having locked access to a file like VSS. "What if I work on something while Bill does?" Again, this is a good indicator that their code architecture is hurting and they haven't really paid attention to separation of concerns. That is a huge issue with separation of concerns, but it also says that they haven't used source control all that seriously. Merging potentially conflicting files shouldn't be difficult unless you're both implementing the same thing in different ways. If you're doing that, you've got bigger problems than just code.
|
|
#
?
Feb 14, 2010 19:16
|
|
