As I am digging further into this though, I am coming up with a lot of
questions. I am guessing, based on the fact that I am seeing whiteboards,
etc. that committers don't really have their own forks in our current
apache model, but rather everyone is using their own clone of the same
fork. Am
The code could vary widely.
A session id is usually a string returned from the server at login. Does
your server return it? And then after that I think it depends the API.
Hopefully the URL you will pass into navigate URL will take the session id
as an argument as in:
http://my.app.com/myNew
yes..but in that case i need a small amount of..then i can try to modify
those thing.
On Sun, Mar 24, 2013 at 9:45 AM, Alex Harui wrote:
>
>
>
> On 3/23/13 1:25 PM, "Madhu Dutta" wrote:
>
> > can you send me a code snippets?
> I'm not sure it is safe to put the password in the URL. I think the
The whiteboard was migrated from SVN, and I think folks did just copy SDKs
in there so there is no common branch points. I wouldn't worry about a
workflow for whiteboards, I want to get the workflow for flex-sdk,
flex-falcon and flex-asjs in the wiki as that is where we have multiple
folks working
>I'd rather see links to the best example elsewhere on the net or short stories
>as to what rebase does, or why cutting a branch saved your ass, along with
>steps to do it and what those steps are doing. Git seems >powerful enough
>that if you don't know what you are doing you can make a lot of
>It kind of bugs me that there are multiple ways to do things in Git (stash or
>don't stash, add or direct commit) and it represents a vastly different way of
>thinking than SVN, VSS or Perforce, but so far, I'm liking it.
Yes although in this case it's because there are multiple tools. They are
Hi Guys,
Sorry for writing in this late in your discussion. I really appreciate the
time you both are putting into this.
I finally got a chance to look at the wiki page. IMO, if you want to
simplify, I think the first thing I would put on the wiki is the "update the
readme" workflow. Most of u
On 3/23/13 1:25 PM, "Madhu Dutta" wrote:
> can you send me a code snippets?
I'm not sure it is safe to put the password in the URL. I think the session
id is the most often used solution.
>
> On Sat, Mar 23, 2013 at 11:45 PM, Angelo Anolin
> wrote:
>
>> I think one possibility is to call a
On 3/23/13 10:07 AM, "Michael A. Labriola"
wrote:
>> OK, nice story. But for me, I have no idea how you "pull in his changes and
>> review". Or "go back and test against unmodified code". And are you
>> stashing or committing your changes first? What git commands and >flags do
>> you use?
[
https://issues.apache.org/jira/browse/FLEX-28915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611941#comment-13611941
]
c sills commented on FLEX-28915:
Hi Alex.
Yes it does fail in the emulator as well.
Sorry, I read this thread too quickly, and without thinking. FXG -> SVG.
I was talking about going in the other direction. Parsing and displaying
SVG or FXG in Flash (Dynamically, at run time). Nevertheless, if someone
is interested in that - you may find my comment useful.
On Sat, Mar 23, 20
No worries..just commited an updated DateFormatter. Thanks for reviewing.
cyrill
On Sat, Mar 23, 2013 at 12:22 AM, Alex Harui wrote:
> This is being picky, but you have too much whitespace here:
>
>> +public function DateFormatter(formatString : String = null)
>
> Should be:
> public fun
Okay, I have a long plane flight tomorrow
I thought you had a cape !?#** :-)
-Fred
-Message d'origine-
From: Michael A. Labriola
Sent: Sunday, March 24, 2013 1:33 AM
To: dev@flex.apache.org
Subject: RE: [Git/Wiki] please review the proposed workflow and comment
Yes please.
Okay,
>Yes please.
Okay, I have a long plane flight tomorrow. I will try to write something up so
I can send it when I land.
>No problem, it just a talk, you and me want the best for Apache Flex.
Thanks. Looking forward to figuring this out and helping everyone else get
comfortable with git
Mike
Would you mind if I wrote up a proposed alternate that doesn't use rebase
and eliminate fast forwards? Yes, it will mean there is an extra 'useless'
commit... which I don't actually always find useless, but I think it
simpler. Then let's just discuss.
Yes please.
I am not trying to assert my
>In what do you disagree, in what I'm technically stating or the fact I thing
>is better to have a clean, linear and readable history for the cost of not
>even an extra step if they follow the guideline ?
>I can create a simulation with 1 bare repo and 2 clones to demonstrate my
>point if needed
We just disagree. How shall we proceed?
In what do you disagree, in what I'm technically stating or the fact I thing
is better to have a clean, linear and readable history for the cost of not
even an extra step if they follow the guideline ?
I can create a simulation with 1 bare repo and 2 clo
>As I said before, at least at the beginning, I wouldn't like committers new in
>git have a chance to run into problems and in the same time I wouldn't like
>they have to think to much about what should he use in that >situation, that's
>the reason why I created this workflow and for sure if the
It is exactly what I want too while I want it works in every situations, I
guess it is good you here because you've got some git experiences and the
respect of the committers and it's good we can discuss those Git points to
make them clearer.
Thanks,
-Fred
-Message d'origine-
From: M
>Yes, only if there's nothing to merge, as soon as the remote HEAD is ahead of
>my branch HEAD, I'll have an extra merge commit I don't want in order to keep
>a clean, linear and readable history.
We just disagree. How shall we proceed?
that's not actually what rebase is doing. Rebase is rewriting the commit
history so it looks nice. It's not required to keep changes merged
answer in the previous post.
However doing so with pull (or fetch+merge)does the same thing, without
the crazy flags or potential for really bad results
that's not actually what rebase is doing. Rebase is rewriting the commit
history so it looks nice. It doesn't have anything to do with keeping
changes merged
You right, "Rebase is rewriting the commit history so it looks nice" and so,
if you have a local merged commit, it will be erased [1] by
Sorry of you get multiple copies of this. I keep getting bounce messages. I
messed up and sent a draft in my last response. I didn't want it to be more
confusing, so, if you can.
Read me instead:
>First of all, I use pull with the rebasing option to keep my work on top of
>what the others a
>That's only an example of how you can configure a external merge tool on a
>windows machine, I use P4Merge because it suits me, any other might apply, I
>just shown how it stands in the .gitconfig.
I know, just wondering if we should show it commented out so that others don't
copy and paste an
>I would like to show how to work in collaboration (remote branches) too later,
>if you want to give a hand, I would appreciate it.
I am happy to give a hand but I would like you to consider the idea of keeping
the steps maybe a little simpler at the expense of clean merge lines for right
now.
>First of all, I use pull with the rebasing option to keep my work on top of
>what the others already pushed until there's no issues for my local merges.
>that's not actually what rebase is doing. Rebase is rewriting the commit
>history so it looks nice. It doesn't have anything to do with keepi
can you send me a code snippets?
On Sat, Mar 23, 2013 at 11:45 PM, Angelo Anolin wrote:
> I think one possibility is to call a service or an api from flex that would
> emit a url that is composed of parameters containing the user name and
> password, and the site should be able to have a JS func
Mike,
I forgot one of your point.
I might have missed the reason why, but it seems like there is a perforce
tool coded into the sample gitconfig. Reason?
That's only an example of how you can configure a external merge tool on a
windows machine, I use P4Merge because it suits me, any other m
I think one possibility is to call a service or an api from flex that would
emit a url that is composed of parameters containing the user name and
password, and the site should be able to have a JS function which will
peruse those parameters to log in automatically.
Just thinking something out he
Mike,
One more point, that's true that in some situations, less steps could be
required, my point was to create a workflow that works in most of the cases
without to think too much, I guess with the experience, folks will be able
to manage the workflow as the situation require, at the moment,
Hi Mike,
Thanks for reviewing that, turning back on it I've seen that the step 5 of
"Initial setup" should be the step 1 of "Working on the code" (bad rewrite,
I'm going to take care of that right after I wrote this post :P )
First of all, I use pull with the rebasing option to keep my work o
Thanks Justin. Good work! :-)
I just changed Chris' response to Correct (from Helpful) so it shows
immediately below the question. (One of the perks of being a moderator on
Adobe's forums…) ;-)
Harbs
On Mar 23, 2013, at 1:58 AM, Justin Mclean wrote:
> Hi,
>
> Thanks for everyone who voted an
>I just a bit updated the git wiki [1], can you review it pls ?
>- Answered some the FAQs
>- Added Git configuration info
>- Added the case where time has elapsed between the merge and the push + some
>more details.
Hi guys,
A couple of things. I might have missed the reason why, but it seems l
>OK, nice story. But for me, I have no idea how you "pull in his changes and
>review". Or "go back and test against unmodified code". And are you stashing
>or committing your changes first? What git commands and >flags do you use?
>And the main debate is: if you have a simple change to the
>OK, nice story. But for me, I have no idea how you "pull in his changes and
>review". Or "go back and test against unmodified code". And are you stashing
>or committing your changes first? What git commands and >flags do you use?
>And the main debate is: if you have a simple change to the
ohoh, just found that if you want the thing much more clearer than I can
explain them, it's even illustrated:
http://www.gitguys.com/topics/whats-the-deal-with-the-git-index/
-Fred
-Message d'origine-
From: Frédéric THOMAS
Sent: Saturday, March 23, 2013 4:53 PM
To: dev@flex.apache.or
no, stash doesn't do an add, it saves the stage area and with the -u flag,
the working area too.
-Fred
-Message d'origine-
From: Alex Harui
Sent: Saturday, March 23, 2013 4:40 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
OK, so stash does an add and saves what is in the s
OK, so stash does an add and saves what is in the staging area?
On 3/23/13 8:26 AM, "Frédéric THOMAS" wrote:
> What is committed are in the git storage/history, not the things in the
> stage area, that's an intermediary zone between your working area and git
> storage to prepare your commit.
>
What is committed are in the git storage/history, not the things in the
stage area, that's an intermediary zone between your working area and git
storage to prepare your commit.
-Fred
-Message d'origine-
From: Alex Harui
Sent: Saturday, March 23, 2013 4:12 PM
To: dev@flex.apache.org
Is it different if you have stuff already staged and/or committed?
On 3/23/13 7:52 AM, "Frédéric THOMAS" wrote:
> Hi,
>
> I'm not sure I understand what you ask but your untracked files are here for
> every branches, so it's better to stashed them, your stage area will be
> stashed as well.
>
Hi,
I'm not sure I understand what you ask but your untracked files are here for
every branches, so it's better to stashed them, your stage area will be
stashed as well.
btw, to include untracked files it's "git stash -u", sorry :P
-Fred
-Message d'origine-
From: Mark Kessler
Sent:
Well if he was modifying files in a feature branch then switched to an
entirely different branch to do that testing... would he even have to worry
about stashing or such?
On Sat, Mar 23, 2013 at 10:17 AM, Frédéric THOMAS
wrote:
> I would do that:
>
> git stash (to save your untracked files of t
I would do that:
git stash (to save your untracked files of the branch your working on)
git checkout develop
git log (here get the hash of your HEAD)
git reset --hard (to the point you want to go back in the
history, can be nothing if your current version is stable)
git checkout
Test the bra
OK, nice story. But for me, I have no idea how you "pull in his changes and
review". Or "go back and test against unmodified code". And are you
stashing or committing your changes first? What git commands and flags do
you use?
And the main debate is: if you have a simple change to the README,
[
https://issues.apache.org/jira/browse/FLEX-33408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Kessler updated FLEX-33408:
Attachment: FLEX-33408.patch
Removed the @private tag from the ASDOC comments.
> U
[
https://issues.apache.org/jira/browse/FLEX-28946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Kessler updated FLEX-28946:
Attachment: FLEX-28946.patch
Corrected the null to string conversion for the DataGridColumn compari
Hi guys,
I just a bit updated the git wiki [1], can you review it pls ?
- Answered some the FAQs
- Added Git configuration info
- Added the case where time has elapsed between the merge and the push +
some more details.
Thanks,
-Fred
[1]
https://cwiki.apache.org/confluence/display/FLEX/Git+
Ok, just because I see them as untracked and they're not in svn either.
IIRC, they have been generated I might be wrong ?
-Fred
-Message d'origine-
From: Justin Mclean
Sent: Saturday, March 23, 2013 1:16 PM
To: dev@flex.apache.org
Subject: Re: git commit: Removed files that do actually
Hi,
> I didn't get that, those files are generated, why they shouldn't be ignored ?
> do they have to be committed ?
They are not auto generated, can change and do need to be committed.
Justin
That sounds like all the good way to work with branches to me.
-Fred
-Message d'origine-
From: Michael A. Labriola
Sent: Saturday, March 23, 2013 10:05 AM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith wrote:
I plan to do my Falco
Erik,
Why not let the generic build path targets [1] excluded ?
-Fred
[1]
# building
target
[Bb]uild/
null
tmp
temp
dist
test-output
build.log
release
out
gen
-Message d'origine-
From: erikdebr...@apache.org
Sent: Saturday, March 23, 2013 10:15 AM
To: comm...@flex.apache.org
Subject:
On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith wrote:
> I plan to do my Falcon development work on the 'develop' branch. The full
> nvie model is complete overkill for what I am doing and I don't need umpteen
> feature branches. Has everyone forgotten about KISS?
>
> - Gordon
>
I understand whe
Hi Erik,
If you are talking about the IDE files, it's good to have them here, we
never know which IDE the committer will use, otherwise, yes, you can clean
up unnecessary files/directories.
-Fred
-Message d'origine-
From: Erik de Bruin
Sent: Saturday, March 23, 2013 9:21 AM
To: dev
Hi,
This give me the opportunity to talk about this: shouldn't the project
specific .gitignore files not contain ONLY the files that need to be
ignored for that project? Having some general filetypes/patterns in
there isn't needed and might even cause errors because git wouldn't
pick up files cove
Hi,
You mean that by calling a service from the flex side , I can get the
session id of the webpage in which I want to auto login. Then store that
session id in the browser and open that page in the next tab?
On Sat, Mar 23, 2013 at 11:00 AM, Bogdan DINU wrote:
> Hi,
>
> usually after login, ser
+1
Thanks for having managed that :)
-Fred
-Message d'origine-
From: Om
Sent: Saturday, March 23, 2013 1:07 AM
To: dev@flex.apache.org
Subject: Re: Air 3.7 in Apache Flex
On Fri, Mar 22, 2013 at 4:58 PM, Justin Mclean
wrote:
Hi,
Thanks for everyone who voted and made some noise
Hi Justin,
I didn't get that, those files are generated, why they shouldn't be ignored
? do they have to be committed ?
Thanks,
-Fred
-Message d'origine-
From: jmcl...@apache.org
Sent: Friday, March 22, 2013 10:00 AM
To: comm...@flex.apache.org
Subject: git commit: Removed files tha
57 matches
Mail list logo
