Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Comment: Re:Brand? (Score 1) 227

by Dynedain (#49634425) Attached to: 17-Year-Old Radio Astronomy Mystery Traced Back To Kitchen Microwave

The fridge that came with my condo died last year, my guess based on the design and model number is that it was built sometime around Y2K and was relatively high-end at the time. It even was energy star rated.

My new fridge is bigger and was definitely not the most efficient model on the showroom floor. My electricity bill averages has been at least $30 less each month compared to the previous year. I thought it a fluke the first month because we had been traveling, but it has repeated over and over.

At this rate, the electricity savings alone will pay off the new fridge in 6 years.

Comment: Re:Tabs vs Spaces (Score 4, Insightful) 428

by Dynedain (#49426589) Attached to: Stack Overflow 2015 Developer Survey Reveals Coder Stats

The nominal expansion of tabs is to advance to the next column which is a multiple of 8.

Huh? Since when? On typwriters and early word-processors it was forced to 5 columns. And even most typewriters allowed you to move the tabstops to arbitrary places.

On every editor I've seen in the last 5 years the tab display width is configurable. If you like 2 spaces, great, if you like 8, have at it. It doesn't affect the rest of your team.

The only reason tab characters are a problem is because people mix and match tabs and spaces.

Python's whitespacing is an evil that should be purged with fire.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49426337) Attached to: 10 Years of Git: An Interview With Linus Torvalds

Yes, I have multiple trees for multiple projects. Why on earth would my life be better if I didn't?

Presumably you're not saying something such as "one directory tree for multiple projects is better than multiple directory trees for multiple projects"; that's just the moral equivalent of tabbed browsing vs. non-tabbed browsing, and some people quite legitimately don't find tabbed browsing to be an improvement for them.

Of course not. Every project should have their own repo. SVN, Git or Otherwise. I've seen many places that try to stick it all into one giant SVN project - and the result is that they end up using it as if it was just a network share.

There is precisely one person touching my repository, and that's me, so there's nobody to trip over. Other people's work is separated from my work by being on other people's machines. The ultimate goal of all of our work is to get our changes into the official common repository on the trunk or a release branch; how do branches either on my machine or in the common repository simplify this task?

How do branches make it more difficult? You're intentionally conflating two different use cases. You want to do all your work in master and periodically push to a central server? Fine. I have my devs working on different branches per bug/feature because they may need to pass incomplete work between different developers depending on skillset or what layers of the application stack are being changed. I want to keep them in a branch so the work doesn't slip into a release. When their work is complete, reviewed, and tested, then we merge into a release candidate branch for client review.

Yes, but "having a branch for fixes to a stable release line", to keep feature work for the next release separate from fixes that go into stable release lines (possibly backported from the trunk), is different from "branching for every change you're working on". The former is useful to the project; I've yet to see any scenario in which the latter is useful.

In Git you don't have to have one or the other scenario. You can have both at the same time. Branching off of a release branch and merging later back into that branch is just as simple as branching off of master. Merging and Pull requests allows for flow management on teams that may have owners of various pieces who need to review anything being committed against their branch/module/whatever.

No, I'm complaining that fans of Git seem to think that, because they believe that some particular way of using Git happens to work better for them, it's the Right Answer For Everybody.

I never said that Git is the Right Answer For Everybody - thanks for putting words in my mouth. If your preferred workflow doesn't map to the Git model, then don't use Git. Over the years I have often found that having a flexible worfklow and allowing it to fit the capabilities of the tools being leveraged often introduces more efficient ways of working that I never would have otherwise considered.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49425969) Attached to: 10 Years of Git: An Interview With Linus Torvalds

The way SVN tracks individual file parent/child version relationships across branches (as opposed to Git's compressed delta of the whole project state) easily results in corrupt histories and merge conflicts that aren't really in conflict. It also quickly becomes overly complicated if you want a project structure that doesn't follow the "best practice" of trunk/tag/branches folders where the entire project is branched. (note, that's a community consensus to work around SVN's limitations, not something enforced by SVN itself). In SVN, branching from a branch, or from a tag, instead of branching from trunk, can get you into to the bowels of SVN cleanup and merge conflicts very quickly.

Granted, a nice aspect of SVN is you can have a single file exist at a different revision than the rest of your project - powerful, but very dangerous if you miss that a file is in that state.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49425937) Attached to: 10 Years of Git: An Interview With Linus Torvalds

Without branching, you can only have branch-like behavior by having multiple checkouts. And when you go to resolve those (at least in Git) you will still be doing a merge operation that is identical to merging a branch.

When you have multiple people touching the same project, branching helps keep people's work separated so they aren't tripping over each other, and merging provides a place for reviewing and synchronizing changes across different efforts.

Event CVS and SVN have branching because it is useful. Stop being intentionally obtuse.

You are complaining that you refuse to use one of the very key features of Git, and that somehow that refusal on your part means that Git is hard to use.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49425289) Attached to: 10 Years of Git: An Interview With Linus Torvalds

In Git, every time you check out a new copy you are getting the ENTIRE project history, not just the specific commit. That's part of the nature of a DVCS.

Hence why branching is built to be so easy, and why switching branches is effectively just essentially just changing a symlink.

If you want to be doing dev in another instance thing while a build is running, that's a good argument for a second checkout. But multiple checkouts just to avoid branching is not a good way to use Git, not a good argument against it.

Different VCS architectures result in different workflow styles. What made sense for SVN and CVS doesn't necessarily apply for Git or Mercurial. In SVN/CVS, branching and merging are monolithic tasks that are very cumbersome, so the best-practices workflows tend to minimize how often this happens. Git and Mercurial are the opposite. Because branching and merging is key to making DVCS work, it's highly encouraged and the process is almost trivial by comparison.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49425227) Attached to: 10 Years of Git: An Interview With Linus Torvalds

And use as many dev branches as you want in Git.

I do. I don't want to use any dev branches, as they provide no obvious benefit to me, so I don't use any.

Well if you don't want to branch, then you're arbitrarily enforcing a condition on yourself that makes things far more difficult then they need to be. Because it is a DVCS, Git it built entirely around the idea of frequent branching. Every time you make a commit you are effectively branching.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49423589) Attached to: 10 Years of Git: An Interview With Linus Torvalds

Sounds to me like you try to make huge complex commits. Try rethinking your work as smaller modular commits. It makes life so much easier to do diffs and handling complex branch/merging behaviors.

And use as many dev branches as you want in Git. You can always cherry pick which changes you want to bring over into your master/release branch.

Comment: Re:And yet, no one understands Git. (Score 1) 203

by Dynedain (#49419539) Attached to: 10 Years of Git: An Interview With Linus Torvalds

What if it takes multiple commits to fix a bug? What if you need to commit to run against a build server? What if you want to switch away to a different branch to work on something else without losing where you're at?

It's one click to delete a branch (and it's a simple checkbox when we merge the pull request using Atlassian's git server product). And you don't have to push your changes out to other users or git servers. You can hold onto it on just your box until you're ready to make it available.

Zillions of branches isn't a problem in Git. They're trivial to create and delete. (delete doesn't destroy history, just hides the branch name so it doesn't show in your list of "existing" branches). That's the whole point. Everything is about branching and merging instead of a linear code history.

Whenever people agree with me, I always think I must be wrong. - Oscar Wilde

Working...