#foswiki 2014-03-23,Sun

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***ChanServ sets mode: +o pharvey [00:34]
................ (idle for 1h15mn)
gac410Darn... InterWikiPlugin can't expand a %MACRO% as part of the link. So I can't translate svn rev's to git ref's [01:49]
............ (idle for 57mn)
Simple fix. pass the rendered interwiki link through expandCommonVariables. [02:46]
................. (idle for 1h22mn)
***gac410 has left [04:08]
........................ (idle for 1h59mn)
ChanServ sets mode: +o CDot [06:07]
............................................... (idle for 3h53mn)
ChanServ sets mode: +o Lynnwood [10:00]
.............. (idle for 1h5mn)
ChanServ sets mode: +o pharvey [11:05]
.......................... (idle for 2h6mn)
ChanServ sets mode: +o gac410 [13:11]
.................. (idle for 1h27mn)
gac410Hey CDot I've got a plugin that maps svn rev to git hashref. Implements %REV2REF macro. .. But InterWikis doesn't expand macros, so no easy way to convert Foswikirev: links. Needs a plugin change. :(
Oh.. and good morning :)
[14:38]
CDotexcellent [14:39]
gac410I realized this is a bigger issue ... we ship Foswikirev links in many of our documents. release notes, plugin topics,
Item12819
[14:39]
FoswikiBothttp://foswiki.org/Tasks/Item12819 [ Item12819: Pass Interwiki links through expandCommonVariables ] [14:40]
gac410So we need to consider shipping the plugin ... or decide how to deal with existing sites / documents. I suppose we can keep trac.foswiki.org around, along with an archived svn repo too. [14:41]
CDotCDot isn't getting involved with the git migration. It's not something I particularly want, and I'm concerned that it will damage the project, but I'm a lone voice in the wilderness. [14:43]
gac410hmmm. concerns about damage... that certainly needs to be addressed. lone voice doesn't mean it's not a valid voice. [14:45]
CDotI've already voiced my opinion, but there are enough voices in favour that I'm staying out of it. [14:46]
gac410okay fair enough. Are your concerns in the wiki?
gac410 goes to read
[14:46]
CDotpretty sure they are, but no idea where. [14:46]
gac410Okay... I'll look.
hmpf. You are not on the Foswiki:Development/MoveCodeRepositoryToGit which was the proposal. It mentions decision at FoswikiCamp2011, but nothing referenced there or in the release notes.
[14:47]
FoswikiBothttp://foswiki.org/Development/MoveCodeRepositoryToGit [ MoveCodeRepositoryToGit ] [14:50]
CDotmy basic concern is that git works well when you have a large project with an active core. The active core can act as a "gate" on developments, picking and choosing what to merge with the integration stream.
foswiki is a much smaller affair than that. If we start gitting, I can foresee a rapid explosion of forks as individuals feel their priorities differ from the core stream.
while that can fuel a lot of development, it also poses an imopssible problem for anyone who is trying to create a "golden" distribution - of any part - from the myriad of source trees
[14:51]
gac410I think we will still have one "official" source tree. The "golden distribution" would only be generated from one single repo consisting of the core + default extensions. People who fork can submit "pull requests" to ask us to incorporate changes.
I could see extensions certainly splitting off. I think that
that's a good thing. Our extensions get rather stale, and tbh I'd rather see us not own the stuff that is of lower quality / orphaned.
[14:55]
CDotthe problem would be sealed the first time someone says "That's fixed in MY distribution". That's what would kill us. [14:56]
gac410Unless they also build the Foswiki tgz. If someone else fixes it, we have the opportunity of pulling the fix in, And that is a bit easier process as well. So easier to fork, but easier to merge too.
We've been on github for a couple of years, and have not seen all that much forking.
[14:58]
CDotno, because out infrastructure doesn't favour it (I think).
but you are changing that. making it easier.
[14:59]
gac410hm... but a fork goes "off infrastructure" regardless of what we do. We'll still have one golden repo, and release from that single repo. I don;t think that changes at all. [15:01]
CDotMaybe I'm needlessly negative. If people can make git work, then I'm all for it. But I have my doubts, and I just don't have (or rather, don't want to have) headspace for it. [15:01]
gac410Okay fair enough. [15:02]
CDotCDot has been trying to sort out the mess that configure has become, and is struggling enough with that. [15:04]
gac410I'll get this conversation into the migration topic. If nothing else you can raise an "I told you so" later :D But seriously, we should consider project guidelines and policies to help control / mitigate your concerns. [15:04]
CDotindeed [15:05]
gac410yeah, configure grew into a bit of a monster. I feel badly that I was part of it at times. I think your move of ConfigurePlugin and self-bootstrap is a better longer term approach. [15:05]
CDotit is; but to get there I have to save the checkers, and all the work that went into them. And that's my current nightmare. [15:06]
gac410IMHO there is a lot of value buried in much too much complexity. yeah. [15:06]
CDotI'm guitly of overlapping UI and checker concerns, I always knew that, but it has got completely out of hand.
just finding and eliminating global variables is a nightmare
[15:06]
gac410Yeah Splitting UI and Checker is probably the most fundamental refactor that's needed. That's what kills me. [15:07]
CDotthat should have been done before *any* AJAX was attempted
it's really not that hard at the checker level (I've already done it, mostly) but working out the mess at the top level..... gagh!
[15:08]
gac410You have my sympathies :) [15:08]
CDotI'm close to the point where I just throw away all the existing top level stuff. But I just can't work out what's important and what isn't, because it's all so interleaved.
Ho hum. I even found "goto"s. Spaghetti code. :-(
[15:09]
gac410Well goto isn't really as bad as always represented. But the uses cases are very narrow and it is very easily abused.
Then there are my cobol days, where a real nasty statement "Alter goto" could change a goto to goto somewhere else at runtime. Yeesh.
[15:11]
CDotgotos have no place in OO code, IMHO. I'm not that keen on exceptions, either, but at least they are marginally structured. [15:13]
.... (idle for 15mn)
gac410I've added your comments to Foswiki:Development/MoveCodeRepositoryToGit, And added a Policies section to Foswiki:Development/GitConversionTasks
| Fork control | CrawfordCurrie | How do we keep control on the "golden" core, and avoid a chaos of forks, what is the real Foswiki | |
| Extensions | GeorgeClark | How do we track extensions back to their source repository. Do we apply any controls to Extensions web | |
[15:28]
FoswikiBothttp://foswiki.org/Development/MoveCodeRepositoryToGit, http://foswiki.org/Development/GitConversionTasks [ GitConversionTasks ] [15:28]
...... (idle for 29mn)
gac410CDot ... not sure if it's a bug, but another thing I noticed on t.f.o, Once I've clicked edit on a table, Clicking a button like + moves you to the top-of-page [15:57]
CDotyes, because of the full-page nature of whole-table edit. Use the JS editor, it's much neater.
actually it moves you to the top of the table - it's a #Here style link
[15:57]
gac410Hm... nope. On GitConversionTasks, it always goes to top of page. [15:58]
GithubBot[foswiki] FoswikiBot pushed 4 new commits to master: http://git.io/7SXvHA
foswiki/master bb4a075 CrawfordCurrie: Item12735: added more unit tests for basic table functionality...
foswiki/master e829617 CrawfordCurrie: Item12735: make testrunner a bit more robust in a partially configured environment...
foswiki/master 0cf4b23 CrawfordCurrie: Item12735: the handling of the end-of-table in the ERP showed up some problems with the core table handling code. It works, but it wasn't as robust to pathological cases as I wanted. It is now....
[16:00]
***GithubBot has left [16:00]
FoswikiBothttp://foswiki.org/Tasks/Item12735 [ Item12735: EditRowPlugin addrow functionality destroys table structure ] [16:00]
gac410CDot, ERP ... should the js controls be the default behavior? [16:00]
CDotyes; but it depends on web settings etc [16:01]
gac410gac410 goes poking around ... Maybe we are not getting that default on t.f.o. [16:01]
CDothttp://foswiki.org/Extensions/EditRowPlugin#js
if it's not working there may be a JS error
[16:04]
gac410Hm... So I added js="assumed" to the 2nd table. The edit button disappeared, the row pencils are still there. Drag doesn't actually move rows, No js errors - green checkbox in firefox.
gac410 decides this is one of those plugins he just doesn't understand. :P TML FOREVER!
[16:11]
CDotrow dragging works fine
Chrome
[16:13]
gac410gac410 starts chrome
well chromium
[16:13]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/VboG7Q
foswiki/master 9479f91 CrawfordCurrie: Item12735: row numbering in full-table edit was snafu, meaning row adds were placed at the top of the table instead of the bottom. Also, row deletion was numbered incorrectly....
[16:14]
***GithubBot has left [16:14]
CDotit's really not that different to EditTablePlugin (deliberately) [16:14]
gac410gac410 clicks the little up/down arrow, drags, it "appears" to drag with a ghost of the row. But when he lets go, it drops right back to where it was. [16:15]
CDotCDot just dragged a row, dropped it and it moved
just draggged Item12819 to the top of the table and dropped it. It moved. Then dragged it back to the bottom, and it stuck.
[16:16]
FoswikiBothttp://foswiki.org/Tasks/Item12819 [ Item12819: Pass Interwiki links through expandCommonVariables ] [16:17]
gac410Not for me. Just dragged Item12819 to top, let go, it went right back to the bottom. [16:18]
CDotthat table doesn't have changerows="on", so the controls for adding rows are not there [16:18]
gac410ff and chromium both behave the same way. [16:19]
CDotCDot just used FF to move github up a row - works perfectly.
you *are* logged in, right?
you must be, the JS controls wouldn't be shown otherwise
[16:19]
gac410Something strange is going on. On trunk, of course. Have to log in to get any access. But yes, logged in, [16:20]
CDotcan you look at your JS console please? [16:20]
gac410There is defniitely some strangeness with this plugin. We've seen other issues where stuff that works for one person fails for others. .... over to js console. [16:21]
CDotwith the JS debugger open, do a drag. Are the AJAX requests getting sent?
are the responses sensible?
[16:21]
gac410I don't see any ajax at all in net tab. only error in js console is a 404 on the logo. [16:23]
CDotand in the Network pane? [16:24]
gac410In network panel, drag/drop generates no activity. Clicking yellow corner edit, sometimes works, sometimes issues get erp version=1.2, rc=200, but no edit. [16:25]
CDothuh? What browser version?
what jquery version?
[16:26]
gac410JQuery 2.0.2 Browser Chromium 32.0.1700.77 [16:26]
CDotcan't be the jquery version, cos it's working fine for me on t.f.o [16:27]
gac410That's where I am too. t.f.o [16:27]
CDotso it must be the browser. I'm on chrome 33.0.1750.146
so not that far from your chromium
[16:28]
gac410I went to about:// to find version, then back to page, drag elements still show visually, but no more yellow corner stains. [16:29]
CDothum. Now it's not working on FF for me. Very strange [16:30]
gac410shift-reload. Stains are back. Click stain on empty cell. bunch of agax, little floppy box renders, but no edit window. Click floppy, it POSTs to save, but never gave me an opportunity to actually edit. [16:30]
CDotok, sounds like there's some seriously sick JS on t.f.o [16:31]
gac410gac410 wonders if we should consider doing an alpha build for the masses to praise / curse at :) [16:32]
CDotyellow box editing is working fine in FF for me though :-/
which cell did you click-to-edit on?
[16:32]
gac410Maybe you had some of the working js cached in your browser. github mirror: column Who [16:33]
CDotno, I reset the cache [16:34]
gac410Edit on cells with data works fine for me. Maybe painting a zero width edit field on my browser? [16:34]
CDotI just yellow-stain edited that cell
and pootle integration
both worked fine on empty cells
[16:35]
gac410Hm... I just tried editing your JosephStalin, and it opened, but refused to save - would overwrite your version.
So that's working well ... I just can't edit empyt fields. Trying firefox again.
[16:36]
CDotyeah, that's ok. Refersh and edit again
I was changing behind you
hmmm, I get a zero-sized edit box for an empty field on Chromium. Reckon that's whet you were seeing.
[16:37]
gac410Yes. Firefox works on empty cells, Chromium does not.
I tried just typing in the blind but nothing...
[16:38]
CDotYou typed "Someone"? [16:38]
gac410Yes [16:38]
CDotok, then it did save it [16:39]
gac410No... from ff
Someone from firefox where empty field rendered.
[16:39]
CDotyeah, I can see Chromium has a problem with empty cells. Might be a JQuery change [16:39]
gac410But I can't get the drag stuff to work at all, on either browser. [16:39]
CDotthe drag problem is to do with the cursor. If the table were near the top of the page, it would work
it's failing because your browser is scrolled further down. There is seomething wrong with the offsets.
Bloody JS/DOM :-(
[16:40]
gac410Strange.
Yup... Bingo... you've got it. If I ctrl-minus a few times so it all fits on one page, then drag works.
[16:40]
CDotrow dragging is working fine for me in chromium, though
even scrolled way down
I used jquery calls to get a screen offset; I never quite trusted it. Need to look at the JS again.
[16:41]
gac410Identical behavior on chromium and ff for me. If I shrink the text to get it all on one page, drag works. [16:42]
CDotok, that's useful info, thanks [16:42]
gac410Phew... I was convinced one of us was loosing our minds, And I was at the top of that list. :)
Want me to open tasks for both issues?
[16:43]
CDotone task for both issues, please. I'll get to it some time. [16:44]
gac410Okay. Will do. [16:45]
CDotty [16:45]
gac410Item12820: [16:54]
FoswikiBothttp://foswiki.org/Tasks/Item12820 [ Item12820: Javascript inconsistent operation for edit operations ] [16:54]
gac410We'll get a 1.2 whipped into shape yet! [16:55]
............. (idle for 1h4mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/p5hYUw
foswiki/master 1477467 GeorgeClark: Item9693: Update release notes for ICON changes...
[17:59]
***GithubBot has left [17:59]
FoswikiBothttp://foswiki.org/Tasks/Item9693 [ Item9693: Documentation updates for Foswiki 1.2.0 ] [17:59]
gac410foswikibot: seen wbniv [18:00]
FoswikiBotgac410: Sorry, I haven't seen wbniv. [18:00]
.... (idle for 16mn)
gac410Hey CDot ... any idea if PrefsCachePlugin will ever be released, or if it's even applicable any more? Configure references it. Item10736 [18:16]
FoswikiBothttp://foswiki.org/Tasks/Item10736 [ Item10736: PrefsCachePlugin referenced in configure docs, but not yet released ] [18:16]
CDotNot a clue. What does it do? [18:17]
gac410gac410 doing the hopeless task of reviewing the "release never" tasks. ... or ReleaseNormals [18:17]
CDotaha [18:17]
gac410Hm... You are listed as author. Caches prefs in BerkleyDB instead of in ram. [18:17]
CDotI am? Good grief.
CDot looks at it
[18:17]
gac410Don't spend a lot of time. I just figured you might have been familiar :) Very minor task. Probably ought to be Low not a Normal. [18:19]
CDotI'd be surprised if it still works in 1.2
I have no memory of writing that. Must have done, though. One of those wild, lost weekends.
[18:20]
gac410:) Maybe I'll see if I can comment out the Foswiki.spec. Too much clutter even in the expert parameters. [18:21]
CDotI'd class it as "extremely experimental" and chuck it on the "smells to high heaven" pile :-(
frustrating; that move row problem on t.f.o? Can't reproduce it locally :-/
CDot goes to cook a curry instead
[18:21]
gac410If you add some logging stuff - maybe print out the drop coordinates, I see if I can capture antying
gac410 not all that well versed in js and browsers.
[18:26]
CDotfirst thing is to make sure the code on t.f.o is the same code I'm running here
hum; I can't svn up trunk.foswiki.org
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/usr/home/trunk.foswiki.org'
is too old (format 29) to work with client version '1.8.8 (r1568071)' (expects format 31). You need to upgrade the working copy first.
[18:27]
gac410Ah... did you upgrade your local svn recently?
I've run into that before when I upgrade my local svn client
[18:29]
CDotthis is on t.f.o [18:30]
gac410On the server itself?
shelled in?
[18:30]
CDotshelled in
now I get: svn: E170000: Unrecognized URL scheme for 'http://svn.foswiki.org/trunk'
wtf?
[18:30]
gac410hm... gmc was updating the softare on the server. ... maybe svn was updated.
ping gmc ... you around?
[18:31]
CDotCDot has seen this before, but can't remember the resolution [18:31]
gac410svn upgrade upgrades the metadata of an old working copy. Or another google hit suggested removing .svn and checking out fresh., [18:33]
CDotroot@foswiki /home/trunk.foswiki.org # svn --version
svn, version 1.8.8 (r1568071)
compiled Mar 20 2014, 20:53:16 on amd64-portbld-freebsd8.3
it's a local compile. Suspect it was compiled with http support :-/
without
soddit, my curry is calling.
[18:33]
gac410okay.. good luck [18:35]
ping gmc ... are you around? [18:46]
Hm... Babar, are you around? [18:56]
CDot, gmc ... I actually managed to recompile subversion with the surf option enabled - http: support is restored. Trunk should catch up in about 8 minutes. [19:06]
..... (idle for 21mn)
trunk is back, and up-to-date. [19:27]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/IXkXQg
foswiki/master 54cca5c GeorgeClark: Item9693: check_manifest found issues...
[19:30]
***GithubBot has left [19:30]
FoswikiBothttp://foswiki.org/Tasks/Item9693 [ Item9693: Documentation updates for Foswiki 1.2.0 ] [19:30]
Babargac410: I'm here now [19:32]
.......... (idle for 48mn)
gac410Hi Babar... I'm all set. I was trying to figure out how to rebuild svn client on f.o ... but worked it out.
Thanks anyway
[20:20]
....................... (idle for 1h53mn)
***ChanServ sets mode: +o pharvey [22:14]
.... (idle for 18mn)
ChanServ sets mode: +o pharvey [22:32]
.... (idle for 18mn)
gac410hmpf I'm ending up with svn rev -> github hashes that don't seem to be reachable on github.
I'm beginning to not trust that I've reliably got every svn checking matching a checkin on github. They show up in the git logs but give a 404 on github.
They seem to be svn multi-branch commits. A single svn rev which updated 2 branches - generate two different git hashes, neither of which work using the github web interface.
[22:50]
pharveygac410: if the hash is in your local repo it should definitely be on the remote
otherwise they'r enot the same repo
AFAIK :)
[22:57]
gac410Not that I can find them.
It's consistently a svn cross-branch commit.
Which I didn't even know you could do, but micha does regularly.
[22:57]
pharveyWhich repo? [22:57]
gac410foswiki/foswiki [22:58]
pharveyYeah, it's pretty common. It should work.. [22:58]
gac410svn-commit-xref-master.txt:r17043 | 5638f37 | Item12633: add css for ui-spinner
svn-commit-xref-R11.txt:r17043 | dc376c5 | Item12633: add css for ui-spinner
[22:58]
FoswikiBothttp://foswiki.org/Tasks/Item12633 [ Item12633: cover ui-spinner in foswiki theme ] [22:58]
gac410is an example. Foswikirev:17043 [22:59]
FoswikiBothttp://trac.foswiki.org/changeset/17043 [ Changeset 17043 – Foswiki ] [22:59]
pharveyI only really examined cross-branch commits in the repo-per-extension repos.
You'd think the same would apply to the fat repo though.
[22:59]
gac410I've tried both the short refs 5638f37 and dc376c5 as well as their long versions, both give me a 404 on github.
5638f37e597fe5b098c51259ef62ad81d443ed15 and dc376c574b76a9f0563757ac93b368ce3e5ba432
[23:00]
pharveyis your repo a clone from github? [23:03]
gac410no, a git svn checkout. Interesting The commit is in the per-extension repo, but with a different hash
phone ... brb
[23:04]
pharveyper-extension will definitely have a different hash; it's a different history [23:04]
gac410ugh... I used git svn log --oneline --show-commit to grab all of the svn rev's and the associated git hash
My assumption was we would be able to use that to find all the corresponding commits on github. If the hashes change, we are toast.
I've written a plugin which will convert any of our SVN rev's into a git ref. .. and generated the lookup tables for all branches,
[23:07]
pharveythe hashes should not be different
if they are different, something is broken
different as in different between your local repo and github repo?
[23:09]
gac410I've been spot-checking. 17,000+ to check is a bit much to go through.
Most that I've checked seem fine. It's the ones where I end up with a duplicate.
[23:10]
pharveyI don't understand how a commit can be missing. A missing commit would alter all subsequent commit ids [23:11]
gac410I think it's there, it's just the url doesn't resolve it. [23:11]
pharveycan you see them in git's shortlog?
github*
[23:11]
gac410github shortlog? Is there a web interface? [23:12]
pharveysorry, I just mean github's commit history [23:12]
gac410There seems to be no easy way to jump to a date on the web interface to find what they think the commit is.
I don't have a github clone.
[23:12]
pharveysearch for the task number
I hope it's not something dumb like, github repo ending up with merge commits but your local repo ending up with separate commits due to some difference in the way you're running git svn rebase locally versus whatever our github sync script does on f.o
[23:13]
gac410I suppose I can clone foswiki/foswiki as well. But I'm wondering if it is worth it now. If we are going to repo per extension, then all the refs will change anyway.
running a github clone now. I'll poke around there too. But more importantly, is what I'm trying to do making sense, or is it wasted effort.
[23:13]
pharveythere is a date search thingy on GH
except it seems broken
OH. Damn. That's a UI which searches for repos, hah
[23:16]
gac410Okay. master branch. my git-svn shows 5638f37e597fe5b098c51259ef62ad81d443ed15 for svn r17043. On my github clone, it's 31decbd7c5ad6de9dd3274d5e30021f0e6eb864c
And on github release01x01 branch, same svn rev 17043 is ref 750c203b6b43e585929763026bc4896f1df60f6a
[23:19]
pharveydifferent branch will have different ID due to different history [23:21]
gac410So I've got two flaws in my process. 1) I need to run it against github directly, not my own svn clone. And 2) It's not a 1:1 svn rev -> git hash because of cross-branch commits.
#1 I can fix. #2 is troubling, I implemented a 1:1 relationship.
So there really is no easy way to relate a svn rev to a specific git commit. I'm stumped.
[23:22]
pharveyYeah :/
Which plugin are you working on again?
Is this for tasks web?
[23:26]
gac410Yeah, though since we publish Foswikirev: links in our distro, we might need it in the release as well. [23:28]
pharveySo this is to make the Foswikirev:1234 WikiLinks work? [23:28]
FoswikiBothttp://trac.foswiki.org/changeset/1234 [ Changeset 1234 – Foswiki ] [23:28]
gac410I build a simple plugin with an in-memory array of rev -> hashref. yes indeed.
I was going to change the wikilink so it returns a github url with the %REV2REF{"12345"}% expanded into the equivalent hash
[23:28]
pharveyI wonder if simply linking to master and falling back to other branches where the commit doesn't exist on master is good enough
Or perhaps Release01x01 branch should have priority over master
[23:29]
gac410yeah, though now my builder gets a bit more complex. I was using "sort -u" against the extracted rev's from each branch.
But... if we go to a repo per extension, this gets much more complex.
Now a Foswikirev: needs to be for a hash in a repo.
[23:31]
pharveyAnother option is that we make a rest service which lives on f.o and do the disambiguation/redirection from there
REV2REF could just be a preference variable which produces Eg. http://foswiki.org/bin/rest/Rev2RefPlugin/svnrev=1234
that doesn't sound much simpler though does it :)
just brainstorming
[23:33]
gac410no. And I was trying to expand it into a InterWikiPlugin compatible link. Since that's what lives in all our tasks, release notes, plugin topics, etc.
It would be best, esp. for ReleaseNotes and PluginTopics, that it resolves locally, rather than needing foswiki.org
[23:34]
pharveytrue [23:36]
gac410I like the idea of just using a default branch. [23:36]
pharveyI think that's going to satisfy 99% of people who actually click the link [23:37]
gac410yeah. There is only one dev who regularly does cross-branch checkins. Micha. :P [23:37]
pharveyI think I did a few in the early days :) [23:38]
gac410I didn't even know it was possible. The first time I saw it I thought it was broke.
So... repo per extension. What does that do to this. Will the pseudo-fat (sub-module) repo resolve the hashes ?
Oh... and have you looked at sub-trees vs. sub-modules? There have been a bunch of postings about now bad submodules are.
[23:38]
pharveysubmodules aren't bad, people just use them wrong. Including us :P
The general advice is, if your project has a submodule and you're not specifying a specific tag in that submodule to be checked out, you're doing it wrong
So for example, if TinyMCEPlugin had a TMCE submodule from Moxiecode
and it specified tag v3.4.2
that would be an appropriate use of submodules
[23:45]
gac410I see. That's not what we are doing though is it? Will our _AllDeveloper tag all of the specific extensions? [23:48]
pharveyI don't mean that we should be tagging every commit
I mean that a good use for a submodule is usually something that is reasonably static
you're pointing to a tag which checks out a release-managed version of something
[23:49]
gac410Yes, I understand. It's just that *our* use of them for Extensions doesn' t seem to match that model. [23:50]
pharveyno it doesn't
I usually don't commit my foswiki "superproject"
the only thing I use submodules for is so that I can do "git submodule foreach <do something>"
I absolutely disagree that subtrees are any better though. But perhaps I need to give them more of a chance.
subtrees seem even more convoluted in managing them
[23:50]
gac410I need to figure out how this will work for our releases. And for commit tracking for Tasks. I can see how it will work for a monolithic tree. I'm a bit lost as to how we'll make future commits work for repo-per-extension. [23:52]
pharveymy current thoughts are still that we should have a repo with default extensions in it [23:53]
gac410For ex. Foswikiref:12ba438a points to Foswiki repo. That's fine. But if it's SomeRandomPlugin in the SomeRandomPlugin repo, Foswikiref: won't work. [23:54]
pharveybut I haven't had time to properly consider the ramifications of that
correct
[23:54]
gac410we need Foswikiref:repo/hash or something like that. [23:54]
pharveyThat would be one solutino
solution*
[23:54]
gac410It might even need to be user/repo/hash If we have extensions released from other repos
er other users repos
Either that or we say that Tasks web is for "foswiki" extensions, If it's not released from our repo, then Tasks doesn't apply.
That way joeuser has an extension, they may use the gh tracker, and release from there. Just like an extension that is "not developed in svn"
[23:55]
pharveyAnother way is to have a table somewhere saying which extension has what repo [23:59]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)