| [02:49:41] |
*** |
ders has joined #zipit |
| [03:51:51] |
*** |
ders has quit IRC |
| [04:34:59] |
*** |
drmikecrowe_ has joined #zipit |
| [04:39:33] |
*** |
drmikecrowe has quit IRC |
| [05:36:57] |
*** |
drmikecrowe has joined #zipit |
| [05:44:45] |
*** |
[1]drmikecrowe has joined #zipit |
| [05:54:58] |
*** |
[1]drmikecrowe has quit IRC |
| [05:56:05] |
*** |
drmikecrowe_ has quit IRC |
| [05:57:45] |
*** |
drmikecrowe has quit IRC |
| [06:55:52] |
*** |
g1powermac_PB has joined #zipit |
| [08:30:25] |
*** |
jhaluska has joined #zipit |
| [08:31:41] |
*** |
GPSFan has joined #zipit |
| [08:36:07] |
*** |
drmikecrowe has joined #zipit |
| [08:43:14] |
<jhaluska> |
Morning drmikecrowe |
| [08:43:36] |
<drmikecrowe> |
hey jhaluska, what's up? |
| [08:44:16] |
<jhaluska> |
Not much. |
| [08:44:56] |
<jhaluska> |
I haven't bothered with my ZipIt lately. I'm going to finish setting up a SVN server today. |
| [08:44:28] |
<drmikecrowe> |
Excellent -- what will you be hosting? |
| [08:44:41] |
<jhaluska> |
Just stuff for work |
| [08:44:54] |
<jhaluska> |
My company's work practices are embarrassing |
| [08:45:29] |
<jhaluska> |
Fortunately its mostly just from lack of knowing better. |
| [08:45:33] |
<drmikecrowe> |
hehe, have you used svn before? are you open to another option? |
| [08:47:15] |
<jhaluska> |
I have a bit, and yes I am |
| [08:47:22] |
<Limp_Trizkit> |
if you say cvs, i slap you drmikecrowe |
| [08:47:27] |
<drmikecrowe> |
:D |
| [08:47:45] |
<drmikecrowe> |
No, I'm a convert to mercurial (http://www.selenic.com/mercurial) |
| [08:47:51] |
<Limp_Trizkit> |
ah |
| [08:48:14] |
<jhaluska> |
Is it cross platform? |
| [08:49:00] |
<drmikecrowe> |
completely. |
| [08:49:21] |
<drmikecrowe> |
plus, there's a tortoisehg (if you use windows), and trac support as well |
| [08:49:55] |
<jhaluska> |
Yeah, pretty much I can do what I want assuming its "Cross Platform and Free" heh |
| [08:49:45] |
<drmikecrowe> |
It's all that. What's great, you use it mostly like you program. I commit frequently (whenever I have enough changes). Since the repo is local, it is blindingly fast |
| [08:50:01] |
<drmikecrowe> |
Then, you "push" the repo to the destination, and can merge all together. |
| [08:50:01] |
<jhaluska> |
Any advantages over SVN? |
| [08:51:08] |
<drmikecrowe> |
Well, mercurial (like bazar and git) are distributed version control systems, so it's a bit different than you would expect |
| [08:51:30] |
<drmikecrowe> |
However, one you understand it, it is so much better (for me) |
| [08:52:08] |
<jhaluska> |
Well I've had a little bit of experience with SVN but the previous developer has it backing up to his computer. |
| [08:52:26] |
<drmikecrowe> |
for example, on my linux boxes, I usually go to /etc and do a "hg init" to create a repo, and "hg commit -A" to add everything. Then, I can keep up history of all my changes |
| [08:52:43] |
<drmikecrowe> |
it's built into the directory, not into a central server |
| [08:53:50] |
<jhaluska> |
How do you keep all the distributed stuff up to date and backed up? |
| [08:54:55] |
<drmikecrowe> |
so, you "push" it somewhere. On my servers, I create a repo with "hg init". Then, from my laptop, I do a "hg push ssh://....." and the whole thing goes to the destination |
| [08:54:13] |
<drmikecrowe> |
I keep working, committing locally, then "push" the changes to the host. |
| [08:54:22] |
<jhaluska> |
Interesting |
| [08:54:52] |
<drmikecrowe> |
You can set up triggers on the destination to automatically update the directory when a new version comes in (provided it doesn't branch or have conflicting merges), etc. |
| [08:55:01] |
<jhaluska> |
I'm just trying to figure out which is better for my company's mode of operation, or at least my mode. |
| [08:55:09] |
<drmikecrowe> |
How many developers? |
| [08:55:21] |
<jhaluska> |
uhm 3 or 4 |
| [08:55:48] |
<drmikecrowe> |
Do most build stuff locally, and then you integrate all together to test on a central server? |
| [08:56:24] |
<jhaluska> |
Currently we don't do anything together. |
| [08:56:42] |
<jhaluska> |
Which is something I keep telling my boss is extremely risky |
| [08:56:56] |
<drmikecrowe> |
then this is probably better (IMHO). but, that's because I'm in love with it. |
| [08:57:23] |
<drmikecrowe> |
plus, look who else is using it (mozilla, netbeans, open solaris, etc.) |
| [08:57:55] |
<jhaluska> |
I usually go with whatever has the best support. |
| [08:58:38] |
<drmikecrowe> |
well, the IRC channel is pretty good, and I've never had a problem |
| [08:59:12] |
<jhaluska> |
hmm |
| [08:59:30] |
<jhaluska> |
Does it require a lot of resources? |
| [08:59:34] |
<drmikecrowe> |
So, here's an example: we're working on a major new release for this fall. I did a "hg clone" to create a full copy of the current server software. then, I can develop on a different "branch" that can later be merged back |
| [09:00:35] |
<jhaluska> |
I'm more curious about which is easier to administer. |
| [09:01:48] |
<drmikecrowe> |
have a look at this: http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial |
| [09:02:40] |
<drmikecrowe> |
well, that's a tough question: if you are all peers (and one person isn't driving the final product), then something like this which allows each to have their own repos may be a good option |
| [09:03:42] |
<drmikecrowe> |
again, it suits me very well. ymmv |
| [09:03:55] |
<jhaluska> |
I'm more curious about which I'm likely to encounter more often |
| [09:05:01] |
<drmikecrowe> |
again, I'm biased, so take mine with a grain of salt. however, when you look at the linux kernel going git, mozilla going mercurial, openembedded going monotone, I think there's a move away from svn/cvs to decentralized. |
| [09:04:41] |
<drmikecrowe> |
however, svn has a much wider range of experience/support, though that is changing. |
| [09:04:59] |
<drmikecrowe> |
for me, mercurial was so dirt simple I didn't need much training at all |
| [09:05:24] |
<jhaluska> |
That can be good. |
| [09:07:57] |
<drmikecrowe> |
exactly. for me, I just need lots of small repos for many different projects. svn would have been tough for that usage model |
| [09:09:23] |
<jhaluska> |
We do have a lot of small projects |
| [09:10:10] |
<jhaluska> |
Right now I'm trying to decide between client/server and distributed |
| [09:10:39] |
<jhaluska> |
I'm leaning towards client/server because distributed seems harder to back up unless there is a server that can be backed up |
| [09:11:22] |
<jhaluska> |
Although the distributed looks more flexible than client/server |
| [09:12:05] |
<drmikecrowe> |
that's the key point, for sure. being connected vs. disconnected. On the one hand, you need to be connected with SVN to use it. not so with mercurial. If you are frequently away from the server, you can still commit |
| [09:12:36] |
<jhaluska> |
ok, I think thats a big advantage |
| [09:12:49] |
<jhaluska> |
I have a boss who does development while traveling |
| [09:12:53] |
<drmikecrowe> |
The flip side is driving the discipline to make people commit their changes. As I see it, you have to push people either way: Commit with SVN, or Push with mercurial |
| [09:12:58] |
<jhaluska> |
He usually has internet, but not always |
| [09:13:55] |
<drmikecrowe> |
The nice thing about mercurial is *if* you can show developers the advantage of frequently commiting their work as the develop (get them in the habit of using the tool), then getting them to add a push when connected shouldn't be hard. |
| [09:14:23] |
<jhaluska> |
I think I can do that, although personally I forget too |
| [09:14:34] |
<drmikecrowe> |
convincing a team to use svn just for backup would be more difficult, imho. |
| [09:14:37] |
<jhaluska> |
I was thinking of having it automatically do it every time I do make |
| [09:14:53] |
<drmikecrowe> |
I use it almost like an undo buffer. commit whenever I've changed things a bit and want to go back. it takes longer to type in the message than it does to actually commit |
| [09:15:33] |
<jhaluska> |
Well right now our procedure says to copy the source code to a windows directory. |
| [09:15:51] |
<jhaluska> |
Which blows, mainly because that means I have to use a flash drive. |
| [09:19:25] |
<drmikecrowe> |
this is interesting: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ |
| [09:19:59] |
*** |
CIA-35 has quit IRC |
| [09:27:48] |
<jhaluska> |
drmikecrowe: So ZipIt uses Mercurial? |
| [09:28:39] |
<drmikecrowe> |
in areas, mainly for the server side. but, as you know, i did stay with svn for the trac system for linux.zipitwireless.com |
| [09:30:37] |
<jhaluska> |
Why so? |
| [09:31:32] |
<drmikecrowe> |
why stay with svn for trac? |
| [09:31:38] |
<jhaluska> |
yeah |
| [09:32:28] |
<drmikecrowe> |
mainly speed -- I wanted to use mercurial, but I didn't have enough time to set it up. I needed to get a tool available for the community quickly, and trac was the fastest to set up. |
| [09:32:45] |
* |
drmikecrowe shutters in horror at thinking of setting up gforge |
| [09:33:16] |
<jhaluska> |
Why was svn faster to set up? Previous experience? |
| [09:33:35] |
<drmikecrowe> |
no, it's pretty much built into trac. |
| [09:33:57] |
<jhaluska> |
oh I see |
| [09:34:24] |
<drmikecrowe> |
I needed a wiki+version control+bug system, and trac is pretty much the best bet, though getting the multiple projects to work together was a bit tough |
| [09:34:39] |
<jhaluska> |
Man, I wish I used trac |
| [09:34:27] |
<drmikecrowe> |
yeah, for hosting a single project, it's top of the line |
| [09:34:32] |
<jhaluska> |
oh, the problem is I have to host a lot of projects...small ones |
| [09:34:45] |
<jhaluska> |
I went with TestTrack Pro |
| [09:35:34] |
<drmikecrowe> |
hmm, haven't seen that one before |
| [09:35:57] |
<jhaluska> |
It's not Open Source and the licensing is expensive. |
| [09:36:20] |
<jhaluska> |
But it's cross platform and has good customization for the work flow. |
| [09:37:07] |
<drmikecrowe> |
why not gforge? |
| [09:38:01] |
<jhaluska> |
Well, 1. I was familiar with TestTrack. 2. I didn't even know gforge existed |
| [09:38:54] |
<jhaluska> |
hmm, brings up a good point I need to see if TestTrack integrates with SVN or something like that. |
| [09:39:19] |
<drmikecrowe> |
well, gforge is definitely the standard for open-source projects (http://luaforge.net/ for example) |
| [09:39:26] |
<jhaluska> |
Well look at that, Subversion 1.4 |
| [09:39:27] |
<drmikecrowe> |
but, its a beast to configure |
| [09:44:22] |
<jhaluska> |
Well thanks for letting me know more about it, but I think I'm going to stick with SVN |
| [09:44:31] |
<jhaluska> |
Only cause it apparently integrates with TestTrack |
| [09:44:50] |
<jhaluska> |
Although I was about to go with mercurial |
| [09:44:59] |
<jhaluska> |
It's storming here, power/internet may go out |
| [09:50:53] |
<jhaluska> |
Well hello Mr Lightening and Thunder |
| [09:51:11] |
<echelon> |
hey guys! |
| [09:51:21] |
<echelon> |
wow.. people are actually talking in here |
| [09:51:35] |
<jhaluska> |
It happens |
| [09:51:39] |
<echelon> |
so.. 1 question |
| [09:51:47] |
<jhaluska> |
Usually the secret to getting people to talk, is to talk yourself. |
| [09:52:09] |
<echelon> |
with buildroot, you're using the kernel z2 ships with? |
| [09:53:40] |
<echelon> |
the z2 shell hack rather |
| [09:54:18] |
<echelon> |
am i on the right track? |
| [09:54:54] |
<drmikecrowe> |
actually, I don't know. are people typically using our kernel, or have they flashed another? I haven't kept up enough |
| [09:56:14] |
<echelon> |
but with OE you use a freshly built kernel, ja? |
| [09:57:26] |
<drmikecrowe> |
oe can build one, yes. but I *think* (and don't rely on this) that oe will also build just the application you want, and you can run it in the z2 shell hack. I think this is what T0mW had set up |
| [09:58:37] |
<echelon> |
i spoke with GPSFan, he said with buildroot, you link against uclibc |
| [09:59:10] |
<echelon> |
and OE uses glibc |
| [09:59:42] |
<echelon> |
so i'm guessing you need the entire image |
| [09:59:46] |
<drmikecrowe> |
we'll be moving to uclibc later this year, I hope. free up some space |
| [10:00:27] |
<echelon> |
cool |
| [10:01:56] |
*** |
CIA-45 has joined #zipit |
| [10:01:58] |
<echelon> |
so if you can use the original z2 kernel, shouldn't the wifi/audio support be already available if you just use the z2 shell hack? |
| [10:03:23] |
<drmikecrowe> |
that's what I think, but, remember I haven't gotten as far as you guys have (just haven't had time yet) |
| [10:03:45] |
<echelon> |
kk :) |
| [10:04:17] |
<echelon> |
so i guess i'll stick with z2 shell hack/buildroot for now :P |
| [10:04:39] |
<echelon> |
now to figure out how to use buildroot |
| [10:04:47] |
<drmikecrowe> |
well, didn't you say buildroot did uclibc? will that work with the existing kernel/shell? (I don't know, just asking) |
| [10:06:22] |
<echelon> |
yeah, GPSFan was able to build apps with it |
| [10:06:53] |
<echelon> |
iirc, z2 itself uses uclibc |
| [10:08:33] |
<drmikecrowe> |
nope, not yet |
| [10:12:09] |
<echelon> |
can you open up multiple virtual terminals with tinybox? |
| [10:13:34] |
<echelon> |
like what happens when you do alt + f{1-8} |
| [10:14:41] |
<echelon> |
because when the wifi card disassociates itself from the ap while you're in the middle of an ssh session, there isn't much you can do besides resetting it |
| [14:04:49] |
*** |
g1powermac_PB has quit IRC |
| [16:09:14] |
*** |
g1powermac_PB has joined #zipit |
| [17:05:02] |
*** |
jhaluska has quit IRC |
| [17:44:56] |
*** |
g1powermac_PB has quit IRC |
| [17:56:09] |
*** |
GPSFan has quit IRC |
| [18:09:20] |
*** |
drmikecrowe has quit IRC |
| [18:33:51] |
*** |
FireEgl has quit IRC |
| [18:45:15] |
*** |
FireEgl has joined #ZipIt |
| [20:48:28] |
*** |
ders has joined #zipit |
| [20:51:22] |
*** |
ders has quit IRC |
| [21:58:50] |
*** |
drmikecrowe has joined #zipit |
