Search Results

Search found 5 results on 1 pages for 'matrixfrog'.

Page 1/1 | 1 

• How can I tell Notepad++ to always use a particular language with a particular file extension.

  - by MatrixFrog

  I've associated .xul with Notepad++ so if I double-click on a .xul file, it will open in Notepad++. But Notepad++ doesn't know that XUL is just a particular type of XML, so I then have to manually click on "Language XML" to get XML syntax highlighting. Is there a way that I can tell it: "every time you open a file with the extension .xul, automatically switch to the XML language"?

  Read the article

• Eclipse keyboard shortcuts: "alt+shift+" vs. "shift+" vs. "ctrl+alt+" etc. -- Is there an underlying

  - by MatrixFrog

  There are a zillion questions on SO about keyboard shortcuts in Eclipse, but there's I've always wondered if there is an underlying logic to the decisions of which shortcuts would be ctrl+alt+[some letter], and which would be just ctrl+[some letter] etc. Obviously there is a need to use a variety of combinations because there are only so many keys on the keyboard, but why, for example, is "add import" ctrl+shift+m, while "extract method" is alt+shift+m, instead of the other way around? I think if there is some underlying logic to these decisions, it will make it easier to remember more shortcuts without having to scan through the huge right-click menus to find them, and I won't accidentally use the wrong one as often.

  Read the article

• How to merge a "branch" that isn't really a branch (wasn't created by an svn copy)

  - by MatrixFrog

  I'm working on a team with lots of people who are pretty unfamiliar with the concepts of version control systems, and are just kind of doing whatever seems to work, by trial and error. Someone created a "branch" from the trunk that is not ancestrally related to the trunk. My guess is it went something like this: They created a folder in branches. They checked out all the code from the trunk to somewhere on their desktop. They added all that code to the newly created folder as though it was a bunch of brand new files. So the repository isn't aware that all that code is actually just a copy of the trunk. When I look at the history of that branch in TortoiseSVN, and uncheck the "Stop on copy/rename" box, there is no revision that has the trunk (or any other path) under the "Copy from path" column. Then they made lots of changes on their "branch". Meanwhile, others were making lots of changes on the trunk. We tried to do a merge and of course it doesn't work. Because, the trunk and the fake branch are not ancestrally related. I can see only two ways to resolve this: Go through the logs on the "branch", look at every change that was made, and manually apply each change to the trunk. Go through the logs on the trunk, look at every change that was made between revision 540 (when the "branch" was created) and HEAD, and manually apply each change to the "branch". This involves 7 revisions one way or 11 revisions the other way, so neither one is really that terrible. But is there any way to cause the repository to "realize" that the branch really IS ancestrally related even though it was created incorrectly, so that we can take advantage of the built-in merging functionality in Eclipse/TortoiseSVN? (You may be wondering: Why did your company hire these people and allow them to access the SVN repository without making sure they knew how to use it properly first?! We didn't -- this is a school assignment, which is a collaboration between two different classes -- the ones in the lower class were given a very quick hand-wavey "overview" of SVN which didn't really teach them anything. I've asked everyone in the group to please PLEASE read the svn book, and I'll make sure we (the slightly more experienced half of the team) keep a close eye on the repository to ensure this doesn't happen again.)

  Read the article

• How to merge an improperly created "branch" that isn't really a branch (wasn't created by an svn cop

  - by MatrixFrog

  I'm working on a team with lots of people who are pretty unfamiliar with the concepts of version control systems, and are just kind of doing whatever seems to work, by trial and error. Someone created a "branch" from the trunk that is not ancestrally related to the trunk. My guess is it went something like this: They created a folder in branches. They checked out all the code from the trunk to somewhere on their desktop. They added all that code to the newly created folder as though it was a bunch of brand new files. So the repository isn't aware that all that code is actually just a copy of the trunk. When I look at the history of that branch in TortoiseSVN, and uncheck the "Stop on copy/rename" box, there is no revision that has the trunk (or any other path) under the "Copy from path" column. Then they made lots of changes on their "branch". Meanwhile, others were making lots of changes on the trunk. We tried to do a merge and of course it doesn't work. Because, the trunk and the fake branch are not ancestrally related. I can see only two ways to resolve this: Go through the logs on the "branch", look at every change that was made, and manually apply each change to the trunk. Go through the logs on the trunk, look at every change that was made between revision 540 (when the "branch" was created) and HEAD, and manually apply each change to the "branch". This involves 7 revisions one way or 11 revisions the other way, so neither one is really that terrible. But is there any way to cause the repository to "realize" that the branch really IS ancestrally related even though it was created incorrectly, so that we can take advantage of the built-in merging functionality in Eclipse/TortoiseSVN? (You may be wondering: Why did your company hire these people and allow them to access the SVN repository without making sure they knew how to use it properly first?! We didn't -- this is a school assignment, which is a collaboration between two different classes -- the ones in the lower class were given a very quick hand-wavey "overview" of SVN which didn't really teach them anything. I've asked everyone in the group to please PLEASE read the svn book, and I'll make sure we (the slightly more experienced half of the team) keep a close eye on the repository to ensure this doesn't happen again.)

  Read the article

• JUnit Theories: Why can't I use Lists (instead of arrays) as DataPoints?

  - by MatrixFrog

  I've started using the new(ish) JUnit Theories feature for parameterizing tests. If your Theory is set up to take, for example, an Integer argument, the Theories test runner picks up any Integers marked with @DataPoint: @DataPoint public static Integer number = 0; as well as any Integers in arrays: @DataPoints public static Integer[] numbers = {1, 2, 3}; or even methods that return arrays like: @DataPoints public static Integer[] moreNumbers() { return new Integer[] {4, 5, 6};}; but not in Lists. The following does not work: @DataPoints public static List<Integer> numberList = Arrays.asList(7, 8, 9); Am I doing something wrong, or do Lists really not work? Was it a conscious design choice not to allow the use Lists as data points, or is that just a feature that hasn't been implemented yet? Are there plans to implement it in a future version of JUnit?

  Read the article

1