Time |
S |
Nick |
Message |
02:59 |
|
pdurbin |
now that we're moving to git... i'm pretty sure we're going to adopt this master vs. develop branch model. the develop branch could be called the "integration" branch: A successful Git branching model » nvie.com - http://nvie.com/posts/a-successful-git-branching-model/ |
04:27 |
|
larsks |
It's a good model. |
11:34 |
|
pdurbin |
i love the diagrams. it's a great post |
11:36 |
|
pdurbin |
the git dev model i've spent more time studying this one, but now i'm thinking it's better geared toward a project that has a primary developer and a few people who sometimes contribute: http://thinkupapp.com/docs/contribute/developers/devfromsource.html |
11:37 |
|
pdurbin |
the nvie.com branch/develop model seems like it'll be a good fit for us since many of us will be writing code at once |
11:37 |
|
pdurbin |
er, master vs. develop branch, i mean |
11:38 |
|
pdurbin |
but those are only branches that stick around |
11:39 |
|
pdurbin |
as the post explains, there are hotfixes that branch from master |
11:39 |
|
pdurbin |
feature branches that branch from develop |
11:39 |
|
pdurbin |
release branches that branch from develop |
11:40 |
|
pdurbin |
all the good code eventually gets merged back into master for a release |
15:10 |
|
|
spilth joined #sourcefu |
15:15 |
|
pdurbin |
spilth: any opinions on git branching? ^^ |
15:15 |
|
spilth |
for developing locally? |
15:16 |
|
spilth |
sorry, looking at log now... |
15:17 |
|
spilth |
I've honestly only really worked on code by myself when using version control |
15:17 |
|
spilth |
But tend to the like developing on trunk and checking in code that works |
15:18 |
|
spilth |
when you do a release, create a release branch to manage bugs on it separately from the development going in trunk/master |
15:20 |
|
pdurbin |
yeah, i feel like i'm more familiar with that model... that the latest code goes into master. but i'm coming around to the idea of the latest code going into the develop branch to be later merged into master for a tagged release |
15:20 |
|
spilth |
This is the new hotness for adding functionality on trunk - http://martinfowler.com/bliki/FeatureToggle.html |
15:22 |
|
* pdurbin |
bookmarks http://martinfowler.com/bliki/FeatureBranch.html |
15:24 |
|
spilth |
Feature Branching is essential for people doing Continuous Delivery |
15:27 |
|
pdurbin |
i think that makes sense |
15:29 |
|
spilth |
I am currently doing neither :-| |
15:33 |
|
pdurbin |
:) |
15:38 |
|
spilth |
Though I CAN make changes and have them deployed in about 10 minutes. |
16:05 |
|
pdurbin |
+1 |
16:48 |
|
|
philbot joined #sourcefu |
16:48 |
|
|
Topic for #sourcefu is now http://sourcefu.com | logs at http://irclog.greptilian.com/sourcefu/today |
16:50 |
|
|
raprasad joined #sourcefu |
16:52 |
|
spilth |
Huh. I made a tiny fix to a Ruby project last night and made a pull request. Then I went ahead and made my own changes, pushed them to GitHub and it added those commits to my pull request. I didn't think it would work that way. |
16:54 |
|
pdurbin |
spilth: was it in the same branch? |
16:54 |
|
spilth |
yea |
16:56 |
|
spilth |
He's asking me to rebase my branch so it just has the fix |
16:57 |
|
pdurbin |
i guess you need more branches. one for the fix and one for the other changes you want to make |
16:57 |
|
spilth |
which means I need to rewrite my history a bit, yea? |
16:58 |
|
spilth |
Ah... look right there at the bottom of the Pull Request: "You can add more commits to this pull request by pushing to the master branch on spilth/annyong" |
17:03 |
|
spilth |
I am admittedly lost and confused |
17:03 |
|
spilth |
My git knowledge takes a nose dive after the basic commands. |
17:05 |
|
pdurbin |
mine too :) |
17:06 |
|
spilth |
i'm more likely to just delete it, re-fork it and make the fix :-| |
17:08 |
|
pdurbin |
that's what i'd do |
17:08 |
|
pdurbin |
we all still believe in semantic versioning, right? http://semver.org |
17:08 |
|
spilth |
And all I did was delete a bogus "</body" tag in the code |
17:08 |
|
spilth |
so he could just ignore my pull request and make the fix himself |
17:10 |
|
spilth |
Tried git revert and it caused a problem, of course |
17:11 |
|
pdurbin |
of course :) |
17:11 |
|
pdurbin |
i feel like after the old version ( http://semver.org/spec/v1.0.0.html ) came out, i saw a lot of v1.0.0 as git tags, probably because it says '1. When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0".' |
17:12 |
|
pdurbin |
but the latest version of http://semver.org doesn't have v's... so 1.0.1 for the git tag, it seems |
17:14 |
|
pdurbin |
ah yes. "It is clear to me now that including SemVerTag in the spec was a mistake. It will be removed from the official SemVer 1.0 spec." -- to v or not to v · Issue #1 · mojombo/semver - https://github.com/mojombo/semver/issues/1#issuecomment-2605236 |
17:15 |
|
pdurbin |
so no v :) |
17:15 |
|
|
raprasad_ joined #sourcefu |
17:16 |
|
pdurbin |
huh, but i still see v all over http://git-scm.com/book/en/Git-Basics-Tagging |
17:17 |
|
spilth |
I caved and re-forked :-| |
17:26 |
|
|
raprasad joined #sourcefu |
17:27 |
|
pdurbin |
cool, i now have https://github.com/IQSS/iqss-javaee-template/tree/1.0 after git tag -a 1.0 -m 'tagging master as 1.0' ; git push origin 1.0 per http://git-scm.com/book/en/Git-Basics-Tagging |
17:29 |
|
pdurbin |
and as expected https://github.com/IQSS/iqss-javaee-template/tree/develop gets created from git checkout -b develop ; git push origin develop |
17:32 |
|
spilth |
so far I've only used branches locally... but I stopped doing that as well |
17:32 |
|
spilth |
I'd develop in a branch, then merge it to master, then push to the origin or remote |
17:35 |
|
spilth |
So do I basically have to wait until this guy accepts my pull request before I make any additional changes to master? Does that mean I should've done my fix in a non-master branch? |
17:43 |
|
pdurbin |
spilth: i think you should have made your fix in a non-master branch, kinda like they do here: http://thinkupapp.com/docs/contribute/developers/devfromsource.html |
17:43 |
|
pdurbin |
git branch 100-retweet-bugfix |
17:44 |
|
spilth |
nice |
17:44 |
|
spilth |
looks like a must-read |
17:44 |
|
pdurbin |
i love that thing |
17:45 |
|
pdurbin |
BUT! it clouded my thinking about using git with teams |
17:45 |
|
pdurbin |
please understand that there's a single developer (mostly) in that model |
17:47 |
|
|
raprasad_ joined #sourcefu |
17:47 |
|
pdurbin |
it does seem similar to you FeatureBranch thing though |
17:47 |
|
pdurbin |
your |
17:48 |
|
spilth |
I will give that a try for my next patching endeavor |
17:49 |
|
pdurbin |
i think i'm gonna model my tagging off https://github.com/jquery/jquery |
18:14 |
|
spilth |
That ThinkUpApp diagram is great |
18:32 |
|
|
raprasad joined #sourcefu |
20:43 |
|
|
raprasad joined #sourcefu |
20:44 |
|
semiosis |
found this yesterday, WindowBuilder aka WindowBuilder Pro... https://developers.google.com/java-dev-tools/wbpro/ |
20:45 |
|
semiosis |
an eclipse plugin for building GUIs using swing, swt, and gwt |
20:45 |
|
semiosis |
google donated it to eclipse |
20:45 |
|
crimsonfubot |
http://www.eclipse.org/donate/ |
20:45 |
|
semiosis |
crimsonfubot: lame |
20:45 |
|
crimsonfubot |
semiosis: Error: "lame" is not a valid command. |
20:46 |
|
spilth |
crimsonfubot: learn dammit! learn! |
20:46 |
|
crimsonfubot |
spilth: Error: "learn" is not a valid command. |
20:46 |
|
semiosis |
hah actually it is with the factoids plugin |
20:47 |
|
semiosis |
@learn dammit as i can't help it |
20:47 |
|
crimsonfubot |
semiosis: Error: "learn" is not a valid command. |
20:47 |
|
pdurbin |
patches welcome: https://github.com/pdurbin/greptilian-vagrant/blob/master/modules/server1/files/home/supybot/crimsonfubot.conf |
20:47 |
|
spilth |
crimsonfubot: become self aware |
20:47 |
|
crimsonfubot |
spilth: Error: "become" is not a valid command. |
20:47 |
|
semiosis |
pdurbin: i upgraded (replaced actually) logstashbot, went from mainline supybot to the limnoria fork |
20:47 |
|
semiosis |
much happier with it |
20:48 |
|
pdurbin |
semiosis: ok |
20:48 |
|
pdurbin |
this wbpro is new? |
20:48 |
|
semiosis |
pdurbin: new to me |
20:48 |
|
semiosis |
but apparently not new |
20:48 |
|
pdurbin |
ok. good to know about either way |
20:48 |
|
pdurbin |
thanks |
20:48 |
|
semiosis |
it's included in the main eclipse software repo the juno release, all you have to do is add it through 'add new software' |
20:49 |
|
pdurbin |
isn't javafx the way forward anyway? |
20:49 |
|
semiosis |
is it? |
20:57 |
|
pdurbin |
semiosis: "Is JavaFX replacing Swing as the new client UI library for Java SE?" "Yes. However, Swing will remain part of the Java SE specification for the foreseeable future, and therefore included in the JRE. While we recommend developers to leverage JavaFX APIs as much as possible when building new applications, it is possible to extend a Swing application with JavaFX, allowing for a smoother transition." -- http://www.oracle.com/technetwork/jav |
20:58 |
|
pdurbin |
whoops. here's that link again: http://www.oracle.com/technetwork/java/javafx/overview/faq-1446554.html#6 |
20:59 |
|
pdurbin |
sounds like swing is deprecated |
20:59 |
|
semiosis |
hah far from it |
21:00 |
|
pdurbin |
well, will be |
21:00 |
|
pdurbin |
right? |
21:00 |
|
semiosis |
doubt it will ever be |
21:01 |
|
pdurbin |
but if you were writing a new app... green field... swing or javafx? |
21:04 |
|
semiosis |
tbh i've not looked at javafx in many years, since shortly after its first release. seems to have come a long way since then, and still has a way to go... it's not completely open source, linux support was just added in 2.2, aug '12 |
21:04 |
|
pdurbin |
! |
21:04 |
|
pdurbin |
not open source :( |
21:04 |
|
semiosis |
so i wouldnt rule it out, but it's not the clear choice for all gui apps yet imho |
21:07 |
|
pdurbin |
ok |
21:50 |
|
spilth |
What about Eclipse's UI kit? |
21:51 |
|
spilth |
SWT |
21:51 |
|
spilth |
http://www.eclipse.org/swt/ |
21:58 |
|
semiosis |
windowbuilder supports it too... swing, swt, and gwt |
21:59 |
|
spilth |
ah, missed that |