I created new asserts in the package KernelTests-Numbers of squeak. I cannot find a way to check out these to Squeaksource (a repo) or with monticello. How to check out new tests into the repository http://source.squeak.org/trunk to spread it to the community?
Thanks for the answers in advance.
EDIT
Thanks Tobias.
Here is the Monticello-Code for the Inbox:
MCHttpRepository
location: 'http://source.squeak.org/inbox'
user: ''
password: ''
EDIT 2
Thanks Bert for the Step-by-Step-Manual and screencast link.
Regards,
bartak
The steps are basically
Update so you have the latest trunk versions
Check the package changes against Trunk repo
Make sure only the methods you actually touched are listed
Save your package to the Inbox repo, giving it a reasonable commit message
Here is a video I made about how to submit a new package. Note this is for Etoys, so whenever I talk about the "etoys" repo you need to use "trunk", and instead of "etoys-inbox" you use "inbox". The relevant part is from about 1:20 to 4:00 min:
https://www.youtube.com/watch?v=2QKmfI4taGo#t=1m20s
You put into another repository, called the inbox:
http://source.squeak.org/inbox
From there, Squeak core developers can merge into the trunk repository.
The whole process is described in A New Community Development Model.
You probably want to talk about your changes on squeak-dev.
Related
I am looking into improving the workflow my colleague and myself are using for BitBucket. Something that is often forgotten is the documentation for the feature we are working on therefore I thought I good way to 'don't forget' would be to add a Task as soon as a Pull request is created for a particular branch.
The first think a developer should do after creating the Pull Request would be:
- Add a comment, something like WIP (Work in Progress)
- Create a task underneath, something like 'Add documentation'
In this way, we won't be able to 'Merge' the branch into 'Develop' if All tasks are not completed (this is how it is currenly configured).
Rather than having the developer to do so, it would be good if we can have the system to do so as soon as we create the Pull Request.
Is that possible?
I had searchd on Internet, to be honest I didn't understand if taht functionality comes with like the Premium package or if it is an Add-On...who knows.
Thanks :)
Atlassian recently added a 'Default Pull Request Tasks' feature to Bitbucket Cloud.
The same functionality was previously available as a Bitbucket app, but it was removed in May 2020. It's now a native feature.
Product announcement: https://bitbucket.org/blog/bitbucket-cloud-product-updates-august-2022
Feature details: https://bitbucket.org/blog/default-pull-request-tasks
You can try this. It is free for 30 days.
https://marketplace.atlassian.com/apps/1225598/default-tasks-for-pull-requests?tab=pricing&hosting=datacenter
I did not find any free solutions.
This is unfamiliar to me - I am not used to distributing software in this way, but it seems like everything should be working, unless I have made a mistake.
On Bintray, I'm trying to release a thing I forked as I want to include it as a dependency in my lib and my app, instead of directly. It's also a learning thing, so feel free to educate me if appropriate.
I've uploaded everything correctly I believe, and unlike every other question I've seen - I actually have signed up for an OSS account, but still can't see the "Link to JCentre" button -
Did I do something wrong? Or has something changed?
I also am assuming I may have to wait for a while before I can link it.I can see my version badge and so on, but I want to access this via gradle. The section appears on my package information screen, but it says 0 links and there's no buttons.
Thanks guys!
Here is a link to my (EDIT: [now successfully updated]) repository. It is a fork of Galgo to add support for Android M+
In order to be enable to "Link to JCenter", your repository needs to be public and Maven type, you also can't be a trial user (see answer here).
The problem that you are facing is that your repository if Generic and not Maven.
You can check your repository type by navigating to your repository edit page, you'll find the Type field (which can't be edited). It should say Maven.
You can also check the Owned Repositories from the organization profile page. The text in parenthesis states the repository type.
Does anyone know how to create a branch using the VSO Api. The documentation for Branches doesn't include a "create".
I have been experimenting with doing it via the ChangeSet Api without much success.
This is TFVC, not Git.
Just as what you see in "Branches" page, there isn't any way to create branch with the Rest API. And mostly, you can only read/get the information with the Version Control API for now.
I would recommend you to use Client Object Model Reference if you want to manage the Version Control programmatically. To create a branch, use the "CreateBranch()" method in Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer class.
The REST API apparently does allow one to create branches.
The confusion is that people think that this would be a PUT operation on the Branches endpoint of some kind.
It is not.
In the REST API, a branch is just one more kind of change that is checked in as part of a changeset.
It took me a long time to discover this, myself; and I was using the old SOAP API in the belief, shared by everyone else it appears from what I can find in Q&As on the WWW, that this wasn't part of the REST API.
Of course, using the SOAP API prohibits using .NET 5, because the assemblies only come for .NET Framework.
An abandonware API on an abandonware runtime is not a satisfactory way to talk to source control. ☺
The terrible Azure DevOps documentation gives no clue as to this, except for 1 obscure not-even-a-complete-sentence hidden in a minor class: "List of merge sources in case of rename or branch creation."
The only other clue is what appears in the JSON, from a get changeset changes, that describes the changeset of an already-made branch.
The (also abandoned) Azure DevOps sample code does not contain examples for even deleting an item, let alone branching.
Changesets are checked in via the changeset creation endpoint.
The individual change is a TfvcChange in the changeset's list of changes where:
the version control type (which is a set of flags) contains the branch flag; and
the merge source for the change specifies the source item and the range of changeset numbers.
Branching an entire tree appears to be a matter of branching the directory and all of the files and directories in the directory.
In C♯ or PowerShell, this is a TfvcChange with a VersionControlChangeType of Branch, in a TfvcChangeset passed to TfvcHttpClientBase.CreateChangesetAsync().
I noticed you guys are planning on adding more ORM features into your platform, but in the meantime, is there an easy way to extend your Collections with Mongoose Collections?
You should be able to add:
npm install mongoose
To "admin/generate-dev-bundle.sh"
You can then create a new package and require mongoose, within that you can assign the method to: Meteor.mongoose too and connect to the MONGO_URL (This is Meteors database) for this command. Take a look round the other packages if you need some help.
I did the sample work in this branch:
https://github.com/jonathanKingston/meteor/tree/mongoose
This is 100% untested as I'm on a windows machine at the moment but it should open up:
Meteor.mongoose and just normal mongoose for the standard use as explained here but already connected:
https://github.com/LearnBoost/mongoose#readme
an issue with mongoose is that it won't work on the client. So you'll lose much of the benefit of using Meteor.
Take a look at Collections2 it offers validation and structure.
Good luck!
I am looking for a way to add a post-commit or pre-commit hook to my VCS that will allow me to both create and close a trac ticket in one go.
The use-case is for when a bug has been found, and corrected, but a single developer who wants to make sure the project manager can see the fix has been done, when it was done and what milestone the fix has been done in.
We have a default milestone in trac when creating a ticket, so reflecting that information would be good too.
I recommend extending TracTicketChangesetsPlugin to do this.
You would adjust the way it detects the command in the commit message (see http://trac-hacks.org/browser/tracticketchangesetsplugin/trunk/ticketchangesets/commit_updater.py?rev=8114#L154), as you would not have a ticket number to refer to yet.
See http://trac-hacks.org/browser/tracticketchangesetsplugin/trunk/ticketchangesets/commit_updater.py?rev=8114#L215 for where it actually does the parsing. You would have to return some new token to represent "new ticket."
The code that actually changes the tickets is at http://trac-hacks.org/browser/tracticketchangesetsplugin/trunk/ticketchangesets/commit_updater.py?rev=8114#L234 , so here would you create NEW ticket, then close it straight away. To create a new ticket, call Ticket(self.env) and then save it with Ticket.insert() (see http://trac.edgewall.org/browser/trunk/trac/ticket/model.py?rev=9692#L174 ).
If you do this, I recommend attaching your patch to a new ticket at Trac Hacks.
Create a post-commit hook. Notice how the trac post-commit hooks work and copy this functionality to control this action (creation + closing ticket). The creation + closing are two separate http requests that can happen with wget, you can intercept the ticket creation form's post, look at how the existing trac integration works, or hack it some other way. Have fun. I wish this could be more specific but it really does depend on what you're trying to do.