I would like to know the currently practiced procedure in patching httpunit.
I saw in this thread
Is HttpUnit deprecated / inactive / not supported?
that Russell has put the httpunit source to his github repo.
The FAQ note for httpunit still talks about the svn repo at sourceforge for patching.
If I have a patch, should I use the svn repo and attach the patch to the ticket to source forge's issue tracking or use the repo at github and send a pull request there?
Thanks.
Regards, aki
My name is Wolfgang Fahl and I am one of the committers of httpunit. Thank you for pointing out that the FAQ is outdated regarding the usage of subversion - I am going to fix the FAQ.
The pull request approach seems like a reasonable way to proceed. You might want to make sure that you add
a Junit Test - that shows your change is necessary
-- the test should fail before the change and all other tests should succeed
-- the test should succeed after the change and all other tests should succeed
and the change in the source code
To get the current source code of httpunit you may clone it via:
git clone https://github.com/russgold/httpunit
if you do a
mvn test
the result should like
Results :
Tests run: 822, Failures: 0, Errors: 0, Skipped: 8
With 822/8 being the number of tests as of 2014-02-11 that are executed/skipped.
The Failures should be 0.
Please feel free to add a link to your patch / your pull request here. I appreciate that you are using stackoverflow as a platform for this communication and I hope more of the httpunit users and developers will do so in the future.
This looks like a very good approach; I have to do some work to update the website to reflect it.
Related
I am trying to use svnjs to implement a client SVN on the web. However, the library is not finished, and doesn't work at all. So I've decided to fix it.
For example, when I add a file and commit it I get a 409 Conflict error when uploading the new file. I have found this documentation of WebDAV usage in SVN, although it seems unfinished.
The new file is created within the resulting working collection using a PUT request.
That's all it says. It tells anything about which headers I must include, etc.
So, I have two options/questions:
Where can I find more detailed documentation of WebDAV-SVN?
There are plenty of SVN clients on Windows/Linux. Is there a tool to inspect outgoing and incoming traffic from that specific app, in order to see working examples?
Many thanks in advance!
Thanks to #bahrep 's comment, i found some documentation about how WebDAV/DeltaV works. Here are the links, if anyone is interested:
WebDAV: http://www.webdav.org/specs/rfc4918.html
DeltaV: http://www.webdav.org/specs/rfc3253.html
In my case, I discovered that when receiving a 409 Conflict, the server had to tell me the reason. From there, I have been able to dig a little more into the errors, and finally solve it.
I haven't pushed the working svnjs yet (it was for another project), but I may at one time push it in https://github.com/royalmo/svnjs . If you come from the future and you're still interested, you may go check that repository.
I've been using numtel:pg package for several projects in Meteor. Since Meteor version 1.8 the package isn't working correctly anymore. Anyone can point me to a solution?
The package seems to be abandoned, since there is no update in 4 years(!).
Trying to fix a package that is this outdated is usually not worth the effort. Your best options in this case are
find an alternative package for postgreSQL integration
find a fork of the package, that has fixed the compatibility issues
fork the package yourself and update the NPM versions or transform the package to run without hard wiring to a specific NPM version.
Resources to achieve that:
https://guide.meteor.com/writing-atmosphere-packages.html#peer-npm-dependencies
https://github.com/tmeasday/check-npm-versions
General Readings:
https://guide.meteor.com/atmosphere-vs-npm.html
https://guide.meteor.com/writing-atmosphere-packages.html
What to do if none of this applies to you, because
The alternatives require a lot of refactoring or even changes in the app architecture
There is no fork that keeps the package maintained
You are not skilled enough to fork and update the package yourself
First you should definitely open an issue on the repo and describe your problem as detailed as possible:
Meteor version, postgre version
Meteor version, postgre version where everything worked
What errors do you exactly get? Best is adding a stacktrace, if possible.
if the "error" is rather undesired behavior (not reacting, things disappear etc.) you need a very detailed description of what you did, what you expected, what (not) happened
Add screenshots if possible
Create a minimal repository that reproduces the error/issue and upload it to github; link it to your issue description
Note, that the points above also apply on Stackoverflow as criteria for a "good question". If the repo owner does not respond after a week you may trigger her attention by using #nameOfOwner in the comments.
More resources can be found here:
https://stackoverflow.com/help/how-to-ask
https://stackoverflow.com/help/mcve
By doing all these efforts you raise the chance of some community members to pick up your error (because there is less effort to reproduce when the error is documented well) and fix the issue or fork the repo.
Last but not least the golden way would be to deal with the issue, read about the package and how it works, check the code and try to fix it. Write some tests, document the fix and finally open a pull request in order to share the improvements with all the other package users.
I’ve greatly re-written my plugin and have revamped an upgrade process. I would like to test if it behaves as I expect it to behave when someone updates to this version.
Therefore, the question is, is it possible to force my development website to show a link to upgrade to trunk or even better specific tag (without changing version in repository) of my plugin so that I can test it?
In case someone needs this as well.
According Samuel Wood (Otto/Otto42) to there is Plugin Beta Tester which lets you download and install trunk version or tag with a higher version (I've tested this one).
Since you don't update readme.txt in trunk, users do not get prompted about new version and repository doesn't get updated either so you can fully test new version of the plugin, from start to end without worry about someone getting it before time.
My enterprise has a Git repository. To make changes, I have to make changes in my forked repository and then make a pull request.
I primarily use RStudio, so I have enabled its integration with Git. I can make changes to my forked repository and then push, pull, sync, etc. The problem is that I still have an additional step of logging into GitHub and making a pull request for my forked repository. Is there a way of doing this from RStudio?
I too use RStudio for R development and I do not believe there is a way to do this. The reason is because this is more than just adding code to a branch, you're requesting a management feature to take place which is pulling part of your code into another branch of the code base. RStudio appears to be limited to pulling, syncing and committing. Likely you need to use a separate, more full featured GitHub client.
This could be done via the GitHub API, which could be executed from an R package using the httr or curl package, after which such a package could have an addin for RStudio, which would let you check everything using a nice Shiny app!
Now we only need to look for someone who wants to develop this… Can’t seem to find it (Jan 2022).
We use artifactory as a repo manager. We store packages for releases in repo libs-release-local and snapshot packages in libs-snapshot-local.
For example: If we send the war (web app) into test, it should be from libs-snapshot-local and if it is into stage & prod it will be from libs-release-local.
I will say a scenario, where I needed help below:
Once the war is certified good on test server we would send the same code to stage.
We saw a bug after deployed into stage, so we changed the code and again build it, it obviously cannot go to same versioned release(as in artifactory, we cannot override releases).
So,
What will happen if we recognized 10 bug fixes one at a time, after each deployment in stage ?
What if we have realized there are bug fixes after going to prod.
Artifactory will have bulk of folders with so many version names & folders. Is that good practice? Or else anything senses wrong in our procedure?
Thanks!
Suggest to read Binary repository management Refcard first.
You need define your strategy for your folders and wars (web application), it is already good to use different repo for different purpose (snapshot/release)
The process for maintenance is simple
fix the bug and increase the version, send to the libs-snapshot-local for testing
after testing, a.k.a QA passed, the packages are promoted to release/stage repo libs-release-local again for public use again.
In this case, bug fix is the same as normal development procedure.
or you can refine the questions to make your questions more clear.