15:24:56 <maxandersen> #startmeeting
15:25:02 <jbott> Meeting started Tue Feb 15 15:24:56 2011 UTC.  The chair is maxandersen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:25:02 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:25:21 <maxandersen> so yeah, jbosstools on git is not a trivial thing
15:25:49 <maxandersen> I've kept away from doing it since every attempt on creating  a git copy (besides just  a basic trunk snapshot) have not gone well.
15:25:58 <lightguard_jp> That's cool. May have to look at MeetBot for seam-dev
15:26:18 <maxandersen> i can have it join ya - just say the word ;)
15:26:59 <maxandersen> "not gone well" meaning,  outofmemory errors, weird failures and just the fact it takes hours if not days and if you do it remote weeks to create the git repo.
15:28:06 <lightguard_jp> Using svn2git ?
15:28:19 <maxandersen> if I had all the time in the world I would split up jbosstools repo and create multiple git repos for each major module "set" we got - -but that would involve alot more tedious work and thus im trying to find a easier way to at least starting to dip our toes in a git world.
15:28:29 <maxandersen> using svn2git just fails…i've concluded that now ;)
15:28:34 <lightguard_jp> The git svn clone option works well because you can restart it when it fails and it picks up where it left off.
15:28:48 <maxandersen> using git svn it seem to work now (after git hae received some fixes) but it still takes ages.
15:29:21 <lightguard_jp> With Seam we had it all under one svn repo and split it up into different git repos.
15:29:31 <maxandersen> so i've seen all the explanations of how to use git svn (at least it feels like that) but all of them basically takes weeks to do against jbosstools repo.
15:29:43 <maxandersen> lightguard_jp: seam is *much* much smaller than jbosstools.
15:30:01 <lightguard_jp> Yes, but the basics would still work
15:30:22 <lightguard_jp> I think most of those are done remotely so it takes a while :)
15:31:22 <maxandersen> yes - but mix our other issues of having to use maven with tycho to build osgi and starting to split it all up opens a can of worms or "too many fires" to handle all at once.
15:31:49 <maxandersen> #idea Thus my idea was to get a svn mirror made available in a git repo
15:32:29 <maxandersen> #info have it updated every 15 minutes or so, pushed to github (or whereever) so those wanting to use it doesn't have to wait weeks to have the same repo.
15:33:11 <lightguard_jp> I think that'll end up with a lot of hairpulling too.
15:33:32 <maxandersen> #info once that is setup those that are on git can use dcommit to push their fixes; and those that are to start solving those fires from above now have a muuch faster way of sharing thngs and wont disturb everyone else which is a tendency in svn land.
15:34:13 <lightguard_jp> Sharing between git repos and using svn is not a good idea
15:34:45 <maxandersen> lightguard_jp: this isn't meant to be for the complete team; thus those wanting to try use git and to solve the other issues we have.
15:34:50 <maxandersen> lightguard_jp: why not - I keep hearing tweets/ircs about "it doesn't work" but I find nothing solid in google on it - beyond people having done it an enjoyed it.
15:35:21 <maxandersen> note - I do know it wont be like "full real git" …but its *muuch* faster than fighting with the big svn repo.
15:35:56 <maxandersen> or at least that is my assumption/experience for medium codebases  - now i'm trying to get a mirror to actually see how it works on a big one.
15:36:35 <lightguard_jp> Sure
15:36:44 <lightguard_jp> Well, http://www.kernel.org/pub/software/scm/git/docs/git-svn.html says the git svn init would work
15:37:01 <maxandersen> #link http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
15:37:35 <maxandersen> #link yes - and http://blog.tfnico.com/2010/10/gitsvn-5-centralized-git-svn-mirror.html at least indicates someone tried it as such ;)
15:38:01 <lightguard_jp> Under Caveats it talks about merging and exchanging code with other git users
15:38:47 <lightguard_jp> #link here's what we did with seam, but your usage is much different https://github.com/LightGuard/seam-git-migration/blob/master/seam_git_migration.groovy
15:38:52 <lightguard_jp> Still make be worth looking at though
15:39:41 * maxandersen looking
15:41:15 <maxandersen> lightguard_jp: ah so it just does a git svn clone per module in "old" seam and then adjust tags since the tagging/branches is branches/<modulename> instead of <modulename>/branches - right ?
15:41:19 <lightguard_jp> #info this was for a full git migration
15:41:31 <lightguard_jp> Yep
15:41:41 <lightguard_jp> We didn't want to keep tags so we threw those out.
15:41:55 <maxandersen> so just the full trunk stream /
15:41:59 <maxandersen> ?
15:42:03 <lightguard_jp> Your case of course is different because you want to keep svn info
15:42:14 <lightguard_jp> trunk and tags sorry, threw out branches
15:42:23 <lightguard_jp> But you could do the same thing with branches as well.
15:43:04 <maxandersen> yes - and i think svn2git is supposed to be the one doing this …but doens't…so i probably don't have any way but do it manually or at least semi-manually with a custom script...
15:43:30 <maxandersen> but no matter what we do…it all starts by getting a full git svn clone which you then can work from, right ?
15:43:41 <maxandersen> massage/rewrite history/remove etc.
15:44:36 <maxandersen> #info thys I was thinking - lets get a mirror running so we don't have to redo this over and over again and can start taking the bits and pieces out when we can ready for it.
15:45:00 <nickboldt> maxandersen: you can restrict the starting point to a specific SVN rev #
15:45:10 <lightguard_jp> Yes, you'll need a full mirror
15:45:15 <lightguard_jp> git svn clone should do that for you
15:45:23 <maxandersen> nickboldt: how ? all attempts I tried still started the checkout at rev 1
15:45:32 <nickboldt> you don't read my blog, do you
15:45:36 <nickboldt> ?
15:45:44 <maxandersen> lightguard_jp: what i'm a bit uncertain about is how the rebasing works  - does that update all branches/tags or just the trunk….
15:45:50 <nickboldt> maxandersen: emailed you the link w/ the code (using -s flag)
15:46:19 <maxandersen> #link http://divby0.blogspot.com/2011/01/howto-partially-clone-svn-repo-to-git.html#skiptocode (from nickboldt)
15:46:23 <lightguard_jp> A git svn rebase only updates the local branch and the svn "branch" you're tracking
15:46:35 <nickboldt> maxandersen: what lightguard_jp said.
15:47:17 <maxandersen> lightguard_jp: so if I wanted an automated process I would need to explictly script a git switch to each branch and rebase ?
15:47:38 <nickboldt> maxandersen: why? just USE the branch. when you want to use trunk, switch tehre and use that
15:47:42 <maxandersen> ….so there is not incremental execution of git svn clone ?
15:47:49 <maxandersen> nickboldt: I want a git copy that is uptodate
15:48:03 <nickboldt> I used to have two complete SVN tree dumps - one for latest branch/milestone, one for trunk
15:48:07 <lightguard_jp> git svn fetch will do the whole svn repo
15:48:11 <maxandersen> nickboldt: so every dev doesn't have to understand all the crap that is needed to make this work.
15:48:17 <nickboldt> now I only need the one repo, which includes both trunk and branches' changes
15:48:35 <nickboldt> maxandersen: exactly. All they need to do is pull the repo and pick the branch they want to use
15:48:39 <lightguard_jp> If you're using a local branch you'll need to rebase in those changes from svn
15:48:43 <nickboldt> then connect to it w/ Eclipse and they're done
15:49:27 <nickboldt> http://divby0.blogspot.com/search/label/svn -- more posts about the git-svn experience
15:49:31 <maxandersen> nickboldt: yes…exactly - and I just want a git repo that is uptodate i can clone (fast) compared with some history compared to use git svn fetch/clone for each dev/iteration.
15:49:39 <nickboldt> once we have the mirrored repo in github, though, it's simpler
15:49:54 <maxandersen> nickboldt: yes - that is what i'm trying to do.
15:50:09 <nickboldt> I'm sure you can push from local git-svn mirror repo into github
15:50:33 <nickboldt> once you've done it once, we just need a crontab entry to do it on intervals
15:50:39 <maxandersen> nickboldt: yes - but as said many times …never managed to get a full checkout out to start the mirroring on ;)
15:50:46 <nickboldt> use the -s flag.
15:50:52 <nickboldt> or pull out individual components
15:50:58 <nickboldt> and mirror them one by one
15:51:08 <nickboldt> http://divby0.blogspot.com/2010/11/howto-contributing-to-jboss-tools-using.html
15:51:12 <maxandersen> lightguard_jp: so you are saying git svn clone first a and git svn fetch will keep the git repo updated on all trunk/branches/tags occurring in there ?
15:51:33 <lightguard_jp> Yep
15:51:57 <nickboldt> yes, going forward (but won't get old stuff from before the -s SVNREVNUMBER point)
15:52:01 <maxandersen> nickboldt: *sigh* ….your approaches are impossible to do without a massive sudden git experience come down on the team ;)
15:52:30 <maxandersen> im trying to make it simiple first …and then we can start extract modules…our current build/release is too fragile to do it.
15:52:33 <nickboldt> maxandersen: why? lots of the team already do svn via commandline because tooling doth suck
15:52:55 <maxandersen> nickboldt: svn is svn co <url>; svn update; svn commit …rinse and repeat.
15:53:40 <maxandersen> for each submodule  you create N more steps for git and the mvn tycho build won't work well there unless you are really really really careful.
15:54:20 <nickboldt> disagree. in both cases the first step is "check out build/ and <component>/ folders, then build the parent pom + build the component
15:54:28 <maxandersen> lightguard_jp: okey - so ill try the git clone (its running now …at rev 21656 …only about 20.000 yet ;)
15:54:45 <lightguard_jp> :)
15:54:53 <nickboldt> only thing that changes is "svn co" becomes "git clone" and "svn ci" becomes "git commit; git push"
15:55:11 <maxandersen> nickboldt: yes - and that is what is there today with svn and it even fails there ….which is why adding multiple repos into the mix won't help on the situation ;)
15:55:20 <lightguard_jp> maxandersen: if it dies (unless there's a real error, like naming conflict or something) you can start it back up again with git svn fetch and keep going.
15:55:24 <maxandersen> nickboldt: you forget git clone * N
15:55:30 <maxandersen> lightguard_jp: yup
15:55:47 <nickboldt> maxandersen: I'm talking about the scenario where we have 1 or more github repos
15:55:58 <nickboldt> not the git-svn scenario (which I agree is not for the faint of heart)
15:56:16 <nickboldt> you can restart a failed `git clone` operation
15:56:30 <maxandersen> nickboldt: yes …but that needs to be done much more reliable than we have today. the stuff today breaks too easily.
15:56:49 <nickboldt> but `git svn clone`, not so much. which is why I had to find the -s flag to ignore years of irrelevant, old history
15:57:04 <maxandersen> yes i have the git clone running now on neo6 (a box in neuchatel) where its leaching of a svn mirror so its all local.
15:57:12 <lightguard_jp> nickboldt: -s is an alias for --standard-layout
15:57:34 <lightguard_jp> I've done a git svn clone, had it die then continued with git svn fetch and it worked just fine.
15:57:38 <nickboldt> lightguard_jp: right, and then you add the starting SVNREV # and you get /trunk /branches/ /tags
15:57:46 <maxandersen> nickboldt:  yeah im a bit confused since what I could read is you use git svn clone -r <rev>:HEAD ?
15:57:50 <lightguard_jp> git svn clone is git svn init followed by a git svn fetch
15:58:09 <lightguard_jp> nickboldt: Ah, cool. didn't know that
15:58:29 <nickboldt> lightguard_jp: http://divby0.blogspot.com/search/label/svn#skiptocode
15:58:34 <maxandersen> nickboldt: could you give me the full command line you want me to execute ? the revision Im interested in is 13898 and onwards.
15:59:14 <nickboldt> maxandersen: git svn clone -s 13898 http://svn.jboss.org/repos/jbosstools jbosstools_GIT
15:59:33 <nickboldt> sorry... wait
15:59:40 <maxandersen> ill start such a run next to the other and see if it finshes faster ;)
15:59:51 <nickboldt> git svn clone -s -r13898:HEAD  http://svn.jboss.org/repos/jbosstools jbosstools_GIT
16:00:15 <nickboldt> -r is the rev range (from starting # to HEAD)
16:00:25 <nickboldt> -s is the standard layout, as lightguard_jp says
16:00:30 <lightguard_jp> Of course use your local mirror Max :)
16:00:46 <maxandersen> well that aint what your blog says ;)
16:00:54 <nickboldt> yeah it is
16:01:03 <nickboldt> # Figure out the revision number based on when a branch was created, then  # from r28571, returns -r28571:HEAD
16:01:14 <nickboldt> try RUNNING the code, eh?
16:01:21 <maxandersen> ah…thats…tricky
16:01:31 <nickboldt> ok, then READ the comments? :P
16:01:35 <maxandersen> anyway, when I tried that it still started at rev 1 to checkout.
16:01:39 <maxandersen> but ill try again…2 sec
16:01:44 <nickboldt> huh, odd
16:02:36 <nickboldt> maybe the Mac isn't using the defined variable $rev
16:02:48 <maxandersen> this is on a fedora box
16:03:00 <nickboldt> trys this.... rev=$(svn log --stop-on-copy \   http://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.2.x \   | egrep "r[0-9]+" | tail -1 | sed -e "s#\(r[0-9]\+\).\+#-\1:HEAD#") ; echo $rev
16:03:45 <maxandersen> hmm..the output this time doesnt list all the revision numbers….so might be working this time…weird.
16:03:57 <nickboldt> oh, maybe it's because the earlier branch you're using wasn't done w/ a svn copy
16:04:08 <lightguard_jp> That's possible
16:04:12 <nickboldt> --stop-on-copy might not work if there's not svn copy in the log for the branchpoint
16:04:19 * nickboldt shrugs
16:04:24 <lightguard_jp> If it was done with svn2git then it probably wouldn't work
16:04:38 <maxandersen> nickboldt: hmm - who would not create branches with svn copy ?
16:04:53 <maxandersen> but yeah - that could explain why svn2git got confused.
16:04:57 <nickboldt> maxandersen: dunno, I'm stabbing wildly here cuz it worked for me :)
16:05:23 <nickboldt> maxandersen: what's svn2git? Aren't you just using `git svn clone` ?
16:05:56 <lightguard_jp> svn2git I think was around when git svn wasn't as reliable or when people just wanted a simple one-stop conversion
16:06:03 <maxandersen> #link https://github.com/nirvdrum/svn2git is svn2git i was pointed to as the "better" wayof importing svn into git.
16:06:24 <nickboldt> ah, ok
16:06:30 <maxandersen> …but yeah -  I feel the vibes are very conflicting dependent who and where you ask/read.
16:06:53 <nickboldt> well, we're talking linux tools. very religious bunch. :)
16:06:57 <maxandersen> same about the windows issue of git….some says its fixed others dont
16:07:19 <maxandersen> large files and git also seems to be a problem until you realize big files means >500MB or so ;)
16:07:37 <lightguard_jp> #link http://code.google.com/p/msysgit/ works fine afaik
16:07:46 <nickboldt> maxandersen: used to use TortoiseCVS and TortoiseSVN. Now there's a git flavour: http://stackoverflow.com/questions/1500400/is-tortoisegit-ready-for-prime-time-yet
16:07:50 <maxandersen> well - whatever we need to choose needs to work on the biggest platforms ;)
16:09:34 <maxandersen> i hope to find something like syncrosvnclient for git…haven't looked yet though.
16:10:09 <nickboldt> maxandersen: until you need visual merging, cmdline is pretty awesome. esp if you set up .alias file to save typing.
16:10:49 <nickboldt> eg., "ci" instead of "git commit -m", "stat" instead of "git status", "gp" instead of "git stash; git svn rebase; git svn dcommit; git stash pop"
16:10:55 <maxandersen> …nickboldt: I saw latest updates on egit apparently finally got  the eclipse synchronize feature.....
16:11:30 <nickboldt> that's really all I use. commit, checkout, status, diff, and push (with stash, rebase, dcommit)
16:11:45 <maxandersen> …but i still wonder how we in jbosstools can make this work best since we still have some modules with tight couplings.
16:11:57 <maxandersen> thus changes often crosses mutiple modules.
16:12:06 <nickboldt> too bad that some things get renamed... like svn up becomes git checkout
16:12:30 <lightguard_jp> You could create aliases
16:12:45 <nickboldt> maxandersen: see my last email about swimlanes? we group all the swimmers into one repo together
16:13:58 <nickboldt> gwt, runtime, usage, drools, pi4soa, savara, teiid, bpel, birt, examples, modeshape, portlet, profiles, smooks, tptp ... all individ repos
16:14:02 <maxandersen> nickboldt: well swimlanes will definitely provide guidance on where the splits are. not all swimmers got into the same repo though.
16:14:18 <maxandersen> yes
16:14:33 <nickboldt> then you might combine these: ws, deltacloud, as, archives, jmx
16:14:38 <maxandersen> but before we do that we need very clear instrucitons on how build/release those.
16:14:43 <nickboldt> common+tests
16:14:47 <maxandersen> ws ?!
16:14:52 <nickboldt> jbpm+flow
16:14:57 <maxandersen> that doesnt sound right
16:15:04 <nickboldt> ws depends on as, doesn't it?
16:15:26 <nickboldt> hibernate+freemarker
16:15:30 <maxandersen> less than runtime, bpel and examples depends on AS...
16:15:51 <nickboldt> cdi+jsf+vpe+jst
16:15:56 <maxandersen> ws has a harder build probably - but in context of which changes "together" ws aren't speicial.
16:16:16 <maxandersen> freemarker should be separate - it never moves.
16:16:23 <nickboldt> ws+deltacloud+seam+as+archives+jmx
16:16:34 <maxandersen> but yeah, swimlanes actually comes pretty darn close ;)
16:16:38 <nickboldt> well, that's the other option. as things harden, they get pulled out
16:16:54 <nickboldt> well, a while back you'd said that there were three approaches here we could do:
16:17:01 <nickboldt> 1 UBERBUILD (inefficient)
16:17:05 <maxandersen> hmm - didnt expect seam to be separate from jsf/rf...
16:17:16 <nickboldt> 34+ minibuilds
16:17:20 <maxandersen> btw...
16:17:24 <maxandersen> #endmeeting