You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Jira vs Github :: Agile vs Open Source

September 21, 2014 — JaZahn

A few years ago, my team got into Open Source. Specifically, we started writing all of our apps on github (as opposed to our SVN). We wanted to do this because we wanted to invite scrutiny. We never expected people to look at our stuff, we just felt that by putting it out in the open, we’d want to do better internally.

We went whole-hog. Organized stories with issues, organized sprints with milestones. It was pretty hot stuff. And it was all in the open. Potentially, someone could come by, see what we’re doing and offer to take a story from the backlog of issues. That’s open source. ish. We have a lot more we can do. A lot of growth to do.

Then we started using Jira. The board system within Jira Agile was excellent. Allowed for better organization, reporting!, and visual representations of work. It’s great. It’s Agile. But it also replaced what we were doing with Github issues.

We essentially replaced Open Source in favor of Agile. Our organization is great, we’re keeping track of things fantastically, but we’re no longer open. We don’t have transparency on what we’re working on anymore. People can’t potentially help. Our code is out there, but we’re not inviting. Our process is no longer out there.

So what’s our solution? We don’t have one yet. But what /can/ we do?

We need to put our vision statement out there. We need to put our plans out there. We need to expose what it is we’re doing. We also need to stay agile, keep our tools intact, keep our reporting.

This means we probably need to be duplicating efforts. Open Source and Agile are both hard work and organization. That they can’t line up and be the same effort is not a blocker, just an “oh well”.

Posted in Agile, ATG, Git, Open Source, SVN. Tags: , , , . Comments Off on Jira vs Github :: Agile vs Open Source »

Using SVN with Git

November 7, 2013 — JaZahn

I’ve talked about this before, but I made a pretty picture for it recently to help explain it.

SVN is a centralized repository that we use for controlling deployments, sensitive data, and storing environment specific configs. The majority of the code is contained within Git (github), the development, feature branching workflows etc.

This works well because SVN is good at being central and having a linear history. Git is good at branching and going nuts with workflow.

Posted in Git, SVN, Uncategorized, Version Control. Tags: , , , , . Comments Off on Using SVN with Git »

Git vs SVN again

October 20, 2013 — JaZahn

My previous Git vs SVN made some errors based on old information. I’m hoping this will be a more accurate account.

Git Pros:

  • DVCS (Distributed Version Control System). What this means is it works off of the idea that every user copies the entire VCS and runs their own repository locally. This has several benefits.
    1. Speed. This makes development/working with the repository much faster as almost every operation does not require you to contact the “primary” repository.
    2. Tiny Commits. This allows / encourages tiny commits, so changes are tracked more closely and can be more easily separated out.
    3. Control over who merges. A merge can be attempted by any access layer, but this will generate a pull request which can then be reviewed and approved.
    4. No network access required.
  • Lightweight Branching. While feature branching in SVN is technically possible, it’s also a pain in the ass. Git made branching a first class feature. Easy branching means more people will probably make use of more advanced workflows.
  • Much smaller repositories. Due to better compression.
  • Repo file formats are simpler. So repair is easy and corruption is rare.
  • Clones act as full repository backups. That’s potentially useful I guess.
  • Creating a repository is trivial. So people who want to use repositories to track tiny personal projects, can just do so without any setup.

SVN Pros:

  • Narrow Clones. You can make a checkout of just one subdirectory deep in a hierarchy, download only the files related to that directory, and still be able to make commits. This seems useful in massively large repositories.
  • Authz files are easier (more standard) to write than Git commit hooks.
  • Comfort. People are already used to the linear structure and commands of SVN and that makes sense to them. Switching to DVCS is a cost. Most developers find the switch painful because it goes against what they’ve done for so long.
  • Deals with binary files better. If you’re tracking massive amounts of non-textual data, SVN handles it better as Git’s compression won’t work as well and it’ll be copying over everything.
  • Better classical / hierarchical model. (As opposed to patch/change based revisions.) It keeps in place a simplified model, good for keeping release history. Good for if you only make large commits and don’t want / need to record small dev changes. From a Git perspective, think of fast-forwarding every pull request.
  • SVN Lock. This provides more top down control over the repository.
  • Supports empty directories. This is probably important to someone.
  • Shorter and (mostly) predictable revision numbers.

SVN encourages large commits, Git encourages smaller commits. Simplicity or granularity. We all started out used to the former, but the latter is catching on quickly.

What seems to be the bottom line for most people is that SVN is the old and Git is the new. This is the direction of things, and it’s a new way of thinking about workflows and how VC can actually be doing things OTHER than just storing data.

The only issue that really matters to us is the pain of the switch. The problem is if we don’t understand the benefits that we’re getting from the switch, there’s never going to be enough of an impetus to switch.

Posted in Git, SVN, Version Control. Tags: , , . Comments Off on Git vs SVN again »

SVN vs Git

October 14, 2013 — JaZahn

SVN is a minor improvement on the CVS design. A linear, central repository. To their credit, the developers of SVN acknowledge this, from the Red Book:

Subversion was designed to be a successor to CVS, and its originators set out to win the hearts of CVS users in two ways—by creating an open source system with a design (and “look and feel”) similar to CVS, and by attempting to avoid most of CVS’s noticeable flaws. While the result wasn’t—and isn’t—the next great evolution in version control design, Subversion is very powerful, very usable, and very flexible.

Git is a Distributed Version Control System (DVCS). It’s important to distinguish it as “decentralized”. What that means is that each user creates a literal “fork” of the project.

What Git offers that’s important is lightweight branching and significantly better merging. These are what make advanced workflows (feature branches) possible. See Git Flow.

Branching by itself isn’t where the magic is. What makes Git bounds above SVN is actually the merging. What makes the merging so much better is actually how the history of commits is kept. Git is a Directed Acyclic Graph (DAG) and SVN is done linearly.

What this means is the SVN merge doesn’t take into account previous merges of the branch, it merges the files directly. They’re both doing 3-way merges, but the 3rd that is used (the common ancestor) isn’t the same because the linear history of SVN isn’t taking into account previous merges. So basically SVN goes back way further because it doesn’t know where the last merge between branches was. The result is a lot more conflicts that have to be manually resolved.

The above is outdated. As of SVN version 1.5, (2008), SVN includes meta data on merge histories, so it uses the 3-way merge to similar effect as Git now. I’m going to have to write a new one of these after more research.

https://git.wiki.kernel.org/index.php/GitSvnComparsion
http://stackoverflow.com/questions/871/why-is-git-better-than-subversion/873#873
http://blog.evanweaver.com/2007/08/15/svn-branching-best-practices-in-practice/
http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn

Posted in Git, SVN, Uncategorized, Version Control. Tags: , , . Comments Off on SVN vs Git »

Github zip doesn’t include Submodules

October 18, 2012 — JaZahn

Seriously, what were they thinking. This completely invalidates the use of submodules. We want our code to be available without having to know git. That’s the whole reason they have the download a zip link. But not including all of the code means you have to unzip the code and then use git to get the submodules.

Submodules are great for code reuse. But if I can’t intend my project to be downloaded by people that just want to install it and not code anything while using submodules. This is horrible.

Posted in ATG, Git, Quizmo, Version Control. Tags: , , , , , . 3 Comments »

Inserting images into Github’s wiki

October 2, 2012 — JaZahn

This is something I was not able to find clear information on. Specifically, I wanted to add a flow chart I’d created to the wiki. I’ll also be adding an ER diagram later. It’s cool to have the important development documents somewhere where they can be accessed and perhaps edited from anywhere by anyone if need be. Github has a failing in this regard I think. They should have an interface for this.

The trick of it all is the wiki is itself a git repo. What you have to do is check out that repo. In my case, my project was https://github.com/jazahn/HarvardCards. To checkout that project, you would use the command:


clone git@github.com:jazahn/HarvardCards.git .

But that’s the project. The wiki is:

clone git@github.com:jazahn/HarvardCards.wiki.git .

So you have to check that out, add the image file to it, and then you can [[add the image]] via relative path image link. https://github.com/jazahn/HarvardCards/wiki/Flashcard-Flowchart

Posted in ATG, Flashcards, Git, Version Control. Tags: , , , . Comments Off on Inserting images into Github’s wiki »

Checking your syntax on commit

September 19, 2012 — abarrett

A good IDE can spot programming syntax errors and alert you to them before they ever make it into a git commit. However, sometimes when you’re in a hurry, tired, or distracted, these alerts go unnoticed and there is a greater risk that you’ll commit broken files to your git branch. Git makes it a snap to revert changes, but wouldn’t it be nicer if you could prevent it from happening in the first place?

To that end, git has a nice feature called client-side hooks. In particular, you can create a hook known as a pre-commit hook that executes right before you commit something. It gives you the option to abort if something doesn’t look right. Using this feature, I created a simple script to check PHP and Javascript syntax on commit. It’s helpful for those mornings when I haven’t quite had enough coffee yet.

Posted in Git, Javascript, PHP, Uncategorized, Version Control. 2 Comments »

Using git with svn

August 15, 2012 — JaZahn

If you have the choice, don’t. Pick one and stick with it. My personal preference at this time is git because it facilitates smaller commits — but who cares what I prefer, you’re probably tied to a versioning system based on what someone long before you decided to use.

I for one am tied to svn for doing deploys, but since I’m gaga over git and doing things in the open, I want to use git on a day to day basis and just use svn for deploys.

This sucks, but if you’re going to do it, you shouldn’t be a douche and add your .git directory to svn. That was my first attempt, even though I knew it was bad, I wanted to see the performance hit on svn firsthand I guess.

So I have the deployment related files in svn, so git is free of any environment specific files, like database configs.

So I do all development in git with “.svn” in the .gitignore. That part is easy. Getting svn to ignore git is a little more annoying, especially if you have multiple submodules. So when you’re ready, you add everything to svn, then rm the .git files. It’s better to rm them with the –keep-local flag.

If you delete the .git files because you forgot to –keep-local, or, more likely you’ve had to blow away your development and bring it back via svn, then you have to restore the .git files. Restoring them isn’t so bad:

git init
git remote add origin git@github.com/your_project.git
git pull origin master

Posted in ATG, Git, SVN, Version Control. Tags: , . Comments Off on Using git with svn »

SVN ignoring Git

August 8, 2012 — JaZahn

The first thing I had to deal with was ignoring multiple files in one directory. I’ve always known

svn propset svn:ignore something.txt .

But if you then

svn propset svn:ignore something_else.txt .

it will lose the first ignore. The way to do multiple ignores is annoying:

svn propset svn:ignore "something.txt
> something_else.txt" .

It requires the “s and you have to separate the files with a newline. That’s silly.

So the right way seems to be with an svn ignore file. I created a file “.svnignore”:

.git
.gitignore
.gitmodules

(it doesn’t have to be called .svnignore, that just keeps it straight with me exactly what it is)

Then the following command needs to be run:

svn -R propset svn:ignore -F .svnignore .

and this will recursively run through every directory in “.” and ignore every pattern in the file. The only issue is any time new directories are added that contain git (i.e. submodules) the command will have to be re-run.

Posted in Git, SVN, Version Control. Tags: , , . 2 Comments »

Working with Submodules

July 12, 2012 — JaZahn

I’m using submodules in my current application. All over the place. And I’ve hit some issues with using them properly. Regardless of the warnings I’ve read about, I still did things in the wrong order.


cd ./subm
git checkout master
git commit -a -m "commit to submodule"
git push
cd ..
git add subm
git commit -m "committing submodule's commit to main project"

The thing I’ve done wrong twice now is committing the change to the main project first. That creates a link to a nonexistant commit on the submodule as that is what a submodule is, a link to a specific commit on a different project. The commit has to be done within the submodule first.

Edit: found this after the fact, edited my code to match the code there as it’s more succinct. Stackoverflow has everything
http://stackoverflow.com/questions/5814319/git-submodule-push

Posted in ATG, Git, Quizmo, Version Control. Tags: , . Comments Off on Working with Submodules »
« Older posts «
»