|
Pardot posted:I probably can't post the direct source code, but looking at it, it treats each line that isn't a comment as a shell glob, an d if the file exists, deletes it. So test your lines as shell globs locally.
|
#
?
Jan 31, 2013 14:49
|
|
|
|
| # ? May 13, 2024 20:03 |
|
|
I need some advice on the best VCS to use for our application. I'm working in a medical imaging group where we do analysis on clinical images. Ideally, we'd like a way to keep track of versions for both software and data. We have the following: - Image Data (binary data => shouldn't change after input) - Software Source Code - Analysis Results (binary and text data) The basic idea is that for each project, we wan to have a repository. The idea being that you could sit down at any machine and "checkout" the project and get all of the previous analysis files, image files, and source code you need to work on it. I typically use git for source code but it seems that it doesn't do so well with larger files and binary data. Some of the binary analysis results can be several megabytes each. Additionally, if we include the image data in version control, we could have approximately 1000 100kb images per patient in the study. My initial thoughts would be to put the image data on a central server (either a PACS or just a network share), have a git repository for the source code, and then something to handle versioning of the analysis results. This seems like too many things that a user would have to checkout/clone in order to work on a project. I feel like I'm complicating things. Is there a better way to streamline this process or a VCS that's perfectly-suited for this?
|
|
#
?
Feb 22, 2013 01:27
|
|
|
Under 10mb binaries I would just use a "normal" source control system. Probably would help to do an on-premisis install here. Then again I'm nuts and I've put video in SVN too.
|
|
#
?
Feb 22, 2013 17:04
|
|
|
Stupid question incoming... (need to get familiar with Git and SVN, used TFS for years and I don't know poo poo about the others) Work uses AnkhSVN, are all the various source controls based on Subversion compatible with each other? e.g. I'd be able to use something like TortoiseSVN? Or not necessarily? Also, does Subversion support shelvesets?
|
|
#
?
Feb 26, 2013 16:11
|
|
|
The clients are generally compatible. SVN does not have a concept of shelve -- that is really a DCVS feature in my experience. You might want to look at Git-SVN or HG-SVN where you can work locally in git or hg and then commit to the SVN repo when you get stuff baked enough. When I had to do this stuff in SVN, your option is to export a patch and then roll back to green.
|
|
#
?
Feb 26, 2013 17:18
|
|
|
wwb posted:The clients are generally compatible. See that's all greek to me. I regret using TFS for all my VCS needs.  I'll look into that, thanks.
|
|
#
?
Feb 26, 2013 17:23
|
|
|
Sorry; I probably spend too much time with this stuff. Basically, there are two kinds of version control in the world -- centralized and distributed. Centralized systems have a single database one needs to connect to to do much of anything. Distributed systems basically mean everyone who has checked out the repo has a full fidelity copy of the whole thing. Lots of other differences in terms of workflow but it all springs from this. CVS, TFS (at least in previous versions) and SVN would be centralized. Git, HG and all the stuff the cool kids are on are distributed. Including Microsoft who has announced that they will make TFS work with Git as a SCM back-end. A good start would be to first go read the first parts of the red bean SVN book (http://svnbook.red-bean.com/) and then go hit up http://hginit.com for a good HG intro written for someone used to SVN.
|
|
#
?
Feb 26, 2013 17:43
|
|
|
Mr. Crow posted:See that's all greek to me. I regret using TFS for all my VCS needs. What is wrong with using TFS for all of your VCS needs? It's not as sexy as Git or Mercurial (HG) but it gets the job done. One potential problem is outside of the Enterprise .NET community it's probably hardly installed. Are you leaning SVN for any particular reason? If you want to learn a new VCS go with Git. It's mostly "won" this round of replacing Subversion and will be the go to source control system for the coming decade or so. Every hosted source control website supports Git even the Microsoft ones. The hosted TFS has Git support in a preview mode and native Git support will ship later for the self-hosted TFS. What I am getting at is what are you trying to accomplish?
|
|
#
?
Feb 26, 2013 17:47
|
|
|
gariig posted:What is wrong with using TFS for all of your VCS needs? It's not as sexy as Git or Mercurial (HG) but it gets the job done. One potential problem is outside of the Enterprise .NET community it's probably hardly installed. I have nothing against TFS as a stand-alone product. I started a new job and they use SVN, which is the reason I need to learn it. My only problem with TFS is it's so GUI driven and integrated with VS that I know next to nothing about the other VCS, so the learning curve is going to be annoying. That's really it.
|
|
#
?
Feb 26, 2013 18:11
|
|
|
wwb posted:SVN does not have a concept of shelve -- that is really a DCVS feature in my experience. Shelve is fairly high up on the SVN feature wishlist. It didn't make it into 1.8, but SVN 1.9 may well have it.
|
|
#
?
Feb 26, 2013 19:25
|
|
|
By 'shelve' do you mean 'take my changes from the version and put them somewhere that's not in a commit' like git stash?
|
|
#
?
Feb 26, 2013 20:09
|
|
|
yaoi prophet posted:By 'shelve' do you mean 'take my changes from the version and put them somewhere that's not in a commit' like git stash? Looking at TFS, "kind of, but", if I understand this correctly. It's like git stash in that it lets you store a changeset for later and roll back working to the last commit, but it's also kind of like committing to a pushed WIP branch in that you can use it to share stashed changes with other people without "actually" committing them.
|
|
#
?
Feb 26, 2013 20:25
|
|
|
Zhentar posted:Shelve is fairly high up on the SVN feature wishlist. It didn't make it into 1.8, but SVN 1.9 may well have it. Cool, have pretty much given up on it at this point -- 1.7 clients get you a much better local DB option which we've taken advantage of but anything new is going into HG.
|
|
#
?
Feb 26, 2013 22:28
|
|
|
Coming off the shelving question, and maybe this is more appropriate for the general web thread, what branching strategies do people use for web development? The process at this new job is really annoying, basically all tasks are generally really small really quick tasks to implement and test; we basically only have a release branch, so what ends up happening is you'll have a thousand different "changesets" per task (which is wonderful given the lack of actual shelving options to try and manage crap... at least there are changelists) and you can't check anything in for a given task until it's fully tested and approved by QA. This is really stupid and I'm going to bring a proposal for setting up various branches and automated builds to streamline everything but I have no web background so I'm not sure what the best branching strategy would be for this kind of situation. Also, if it's relevant, we deploy every weekend.
|
|
#
?
Feb 28, 2013 15:09
|
|
|
I'm pretty fond of http://nvie.com/posts/a-successful-git-branching-model/ as a starting point -- we use it on some rather ugly multi-headed multi-stakeholder beasts that tend to have multiple concurrent changes while also keeping a current release branch for emergency patches, etc. We were using a somewhat similar strategy with SVN, challenge there is getting the changes back in from the branches but patch files are a reasonable workaround at times. Teamcity is a godsend here -- it can now work against HG or git branches so you can get really wild with stuff. Also nice is that you could probably live inside the free SKU for teamcity, especially starting out so you aren't going to be asking for more than some space on a VM and some database space you probably already have handy.
|
|
#
?
Feb 28, 2013 15:50
|
|
|
Mr. Crow posted:Coming off the shelving question, and maybe this is more appropriate for the general web thread, what branching strategies do people use for web development? Here's what github does: http://scottchacon.com/2011/08/31/github-flow.html
|
|
#
?
Feb 28, 2013 21:18
|
|
|
Thermopyle posted:Here's what github does: http://scottchacon.com/2011/08/31/github-flow.html This was my original thought on the process but it seemed to... simple. I dunno. Like I had to be missing something. Good to know it's effective! Because I still don't fully comprehend the differences between the two, is there some reason that would make this less effective with SVN vs git?
|
|
#
?
Feb 28, 2013 22:10
|
|
|
That's a pretty good workflow for SVN too (except for pushing to production after one round of code review, yipes).
|
|
#
?
Feb 28, 2013 23:43
|
|
|
If you are deploying as often as they do with small changes I wouldn't get so hung up on that. I'd suspect any sort of massive refactor probably has alot more code review involved.
|
|
#
?
Feb 28, 2013 23:57
|
|
|
Mr. Crow posted:This was my original thought on the process but it seemed to... simple. I dunno. Like I had to be missing something. Good to know it's effective! The main difference with "github-flow" vs. "git flow" is that github does deployments more or less immediately after something is checked into the main branch. If you can do this (and REALLY do this - i.e. your time from checking into master to deploy is less than a couple of hours and fully automated), then git flow adds a lot of ceremony you don't need. If you do have something like manual QA tests, scheduled releases, or anything else that prevents continous deployment, you will get burned by using the github style of doing things. At the end of the day, there's not really an objectively "good" branching model - just ones that are better and worse fits for your workflow.
|
|
#
?
Mar 6, 2013 11:57
|
|
|
enki42 posted:The main difference with "github-flow" vs. "git flow" is that github does deployments more or less immediately after something is checked into the main branch. My friend, who attended a Git course with the Github people last week, said that Github interestingly deploy to production BEFORE pushing to master. Because the master branch is more important than production.
|
|
#
?
Mar 8, 2013 08:44
|
|
|
plotbeltram posted:My friend, who attended a Git course with the Github people last week, said that Github interestingly deploy to production BEFORE pushing to master. Because the master branch is more important than production. yeah, at github they do something like set a tag for production and move it around from branch to branch as they deploy new features, merging things into master once they're more or less sure of their stability
|
|
#
?
Mar 11, 2013 12:20
|
|
|
This is driving me crazy. I'm using the eclipse git tool. Right click->team->commit and it works fine but the diff only shows chunks, I want the whole file. I noticed running git diff from command line shows the same pieces. Doing git diff -u99999 gives me the whole file, but how do I make that the default action?
|
|
#
?
Mar 18, 2013 17:55
|
|
|
Atlassian has released SourceTree for Windows -- an excellent GUI git client that blows just about any of the other windows options I'm aware of away. http://sourcetreeapp.com/
|
|
#
?
Mar 19, 2013 20:41
|
|
|
wwb posted:Atlassian has released SourceTree for Windows -- an excellent GUI git client that blows just about any of the other windows options I'm aware of away. That sounds neat. Does it have explorer integration?
|
|
#
?
Mar 20, 2013 01:19
|
|
|
Volmarias posted:That sounds neat. Does it have explorer integration? If it's anything like the mac version, no, it's pretty self contained, and much more useful as a commit browser than a tree browser, if that makes any sense (I don't even think there's a way to view the file structure at a particular commit). It's a great tool even if you do use the command line pretty heavily though - I personally never use it to commit, but it's great for quick code reviews when I don't want to bother with a pull request, or being able to browse around the commit history and checkout a particular rev or something.
|
|
#
?
Mar 20, 2013 02:23
|
|
|
enki42 posted:If it's anything like the mac version, no, it's pretty self contained, and much more useful as a commit browser than a tree browser, if that makes any sense (I don't even think there's a way to view the file structure at a particular commit). Oh  There's a coworker of mine at work who is notoriously afraid of the command line, and prefers to use windowing systems wherever possible. We hooked him up with TortoiseGit, I'm just hoping for a better solution.
|
|
#
?
Mar 20, 2013 03:19
|
|
|
Volmarias posted:Oh Edit; I prefer SmartGit myself, though for commercial use it's a 79 dollar (perpetual) license. The Gripper fucked around with this message at 06:19 on Mar 20, 2013 |
|
#
?
Mar 20, 2013 06:16
|
|
|
The Gripper posted:I think he meant that it's good to use even if you prefer to use the regular git command line, but you can definitely use it on it's own without the command line if you want. It just doesn't have right-click menus like TortoiseGit does. Yeah, I got what he meant. I was just hoping that it had explorer integration, since that would make the transition for my coworker easier. I'll give this a look for myself when I get into work. Thanks for the suggestion.
|
|
#
?
Mar 20, 2013 13:09
|
|
|
No explorer integration that I can see from here, but everything I've got has tortoise git and tortoise hg installed so I wouldn't see it in all likelihood. I will note it plays well with other tools, so you can use tortoise git to help let you know changes are on the file system -- and even to commit simple ones and then use SourceTree's vastly superior UI to browse the tree and the changelogs. FWIW, I use it pretty heavily on the mac with no finder integration and I find I don't miss it in general. Side note: why can't the guys who wrote tortoise git stop smoking crack and get with the guys who wrote tortoise hg and help craft tortoise-dcvs that does both? As shown, a single tool can work with both repos successfully as the logic from a user standpoint is nearly identical.
|
|
#
?
Mar 20, 2013 15:01
|
|
|
wwb posted:Atlassian has released SourceTree for Windows -- an excellent GUI git client that blows just about any of the other windows options I'm aware of away. This is wonderful and thank you for posting it - I'm working on a yearlong senior project with a fair amount of code and trying to get the other people in my group to use git is like herding cats. I gave them the Github client which is basically a diff viewer plus a commit button which helped somewhat, but it's terrible as far as checking out old versions or resolving conflicts. Maybe I can get them to use this instead. Never write code with bloody electrical engineers. Just never do it (I am an electrical engineer). Arcsech fucked around with this message at 07:51 on Mar 21, 2013 |
|
#
?
Mar 21, 2013 07:46
|
|
|
Volmarias posted:There's a coworker of mine at work who is notoriously afraid of the command line, and prefers to use windowing systems wherever possible.
|
|
#
?
Mar 21, 2013 20:31
|
|
|
ExcessBLarg! posted:Is he tediously slow at repetitive tasks? You wouldn't believe. He'd still rather be using VSS, I think; moving him to SVN was an effort.
|
|
#
?
Mar 22, 2013 02:20
|
|
|
Arcsech posted:This is wonderful and thank you for posting it - I'm working on a yearlong senior project with a fair amount of code and trying to get the other people in my group to use git is like herding cats. I gave them the Github client which is basically a diff viewer plus a commit button which helped somewhat, but it's terrible as far as checking out old versions or resolving conflicts. Maybe I can get them to use this instead. Ugh, sorry. I get to work with designers who see source control as a horrible impediment on creativity -- not the insane enabler we see it as in the development shop. Anyhow, out of curiosity, why did you choose git over HG? Git clients are loads better now, but HG is still easier to use in just about every respect while being powerful enough for just about anything.
|
|
#
?
Mar 22, 2013 14:05
|
|
|
wwb posted:Ugh, sorry. I get to work with designers who see source control as a horrible impediment on creativity -- not the insane enabler we see it as in the development shop. In the past, I've solved that with separating the "work area" for designers from their "delivery area". They can work on files however the like, but always deliver the end result into source control.
|
|
#
?
Mar 22, 2013 18:23
|
|
|
wwb posted:Anyhow, out of curiosity, why did you choose git over HG? Git clients are loads better now, but HG is still easier to use in just about every respect while being powerful enough for just about anything. Mainly because it's what I was most familiar with, I had to use git at an internship and got pretty comfortable with it. Hg is neat and probably what I should have used, but oh well. I might switch over to it for personal stuff and if I had to set up an organization with source control that didn't have it or was switching from something older it might be what I'd recommend now though. Gounads posted:In the past, I've solved that with separating the "work area" for designers from their "delivery area". They can work on files however the like, but always deliver the end result into source control. I'd do this except that unfortunately student projects don't work that way, or at least mine doesn't. It's all constantly works in progress and we aren't nearly organized enough because, well, students.
|
|
#
?
Mar 22, 2013 20:19
|
|
|
I have what's probably a dumb question but I'm a Git newb and don't want to gently caress this up. I have a git repository (I'm on Windows) in C:\Junk\myjunk. I want to keep it as-is, but I also want to create a new repository that resets this repository to how it was a few commits ago. I think I have this right but it seems too easy, will this do what I want?code:
|
|
#
?
Mar 25, 2013 19:46
|
|
|
Sub Par posted:I have what's probably a dumb question but I'm a Git newb and don't want to gently caress this up. I have a git repository (I'm on Windows) in C:\Junk\myjunk. I want to keep it as-is, but I also want to create a new repository that resets this repository to how it was a few commits ago. I think I have this right but it seems too easy, will this do what I want? Probably, but a better question is "why not just use a branch from that point instead of making a new repository?"
|
|
#
?
Mar 25, 2013 19:56
|
|
|
I built out a login system that I want to reuse for a different project. Over several days I added features to it, but I want to easily undo those features and start from the base on project #2.
|
|
#
?
Mar 25, 2013 20:14
|
|
|
|
| # ? May 13, 2024 20:03 |
|
|
Sub Par posted:I built out a login system that I want to reuse for a different project. Over several days I added features to it, but I want to easily undo those features and start from the base on project #2. Try this: code:
|
|
#
?
Mar 25, 2013 20:57
|
|
