This is a question regarding project management and collaboration between developers.
GitHub is now old enough that it includes many abandoned projects. The majority of my https://github.com/issues page is now issues I have opened on projects that have not had commits in years.
I would like to clean up my issues page so I can quickly find the important ones. Is the correct way to do this to just close all issues on abandoned projects?
Yes, closing the issue is the only way to remove it from this view. Note, though, that you can sort by recent activity if you don't mind having many pages of ancient issues. :)
Related
I want to open the issues tab when I open repository because I made a repository just for collecting the tasks for all my project , How can we do that ?
As #VonC has said, this is NOT configurable. It seems that what you require is an issue tracker and not specifically a repository. This articles may help you find an issue tracker that fits your purpose:
http://mashable.com/2014/02/16/bug-tracking-apps/
http://www.thegeekstuff.com/2010/08/bug-tracking-system/
Github's feature for referencing issues in commits automatically just by using the # and referencing commits in issues using the commit hash id is powerful. But is it a maintainable or scalable approach to handle issues from different repositories in one central repository? I do not think so. Issues are important in project development and should be kept organised the same way we keep code clean and organised.
However, this does not mean that it is not possible to maintain your issues in a single github repository. Instead of trying to have the issues tab open automatically, you may create a manual, as a README, for instructions on utilizing the reported issues. This manual will be shown to users visiting the repo. See https://github.com/keybase/keybase-issues as an example. You may find this github article useful in referencing issues.
This doesn't seem to be configurable.
That means you need to open your repo directly at the "Issues" page:
https://github.com/<username>/<reponame>/issues
The google dat.gui is a great little interface. http://workshop.chromeexperiments.com/examples/gui/#1--Basic-Usage
I really want to use this on a new project, but it doesn't work properly on touch screen devices.
However, since they migrated it from Github to code.google.com, things seems to have stalled and issues are going unfixed.
Being brutally honest, I think the project would have more community contribution if it were back on Github. Could I fork it and create my own version, called something like dat.gui MkII, and encourage people to contribute to my version on github? The problem however, is I don't want things to get diluted and create confusion. Would it be better just to completely rebrand it away from dat.gui, and say it was originally forked from there?
Apply a
Cost–benefit analysis
to forking the project.
Cost
forking could dilute the project and create confusion
Benefit
could renew interest in the project and result in more issues being fixed
In my opinion it is worth it, you could alleviate some confusion by having a detailed README on your homepage decribing the situation and/or linking here.
Q: Does Bazaar yet support the ability to duplicate a file and preserve history on both the original and cloned files?
A couple of years ago I was evaluating Bazaar for my company's VCS. There's a lot I really like about it, but one important factor ultimately led us in a different direction: the lack of a bzr copy (or equivalent). This may not be particularly relevant for some teams, but its a pretty common operation for us.
I know the issue was discussed extensively in the past (see references below), but I'm not clear on whether anything was ever implemented.
References
Article on the Bazaar website
Question on AskUbuntu
As you probably saw here, it has not been implemented yet and I'd be really surprised if it happens soon if at all :(
I've been working on an Xcode (iPhone) project with three different persons. We have the project on a Subversion repository, but we still don't completely understand some aspects of the Subversion + Xcode methodology:
1) Each time someone does a commit on a single file, it may appear or not in the project of the other developers. Even though the same person that creates the new files, it adds those files to the Repository and then it commits on those files. Why does that happens? Any suggestions?
2) Each person that is involved on the project can't do a "Commit entire project" without causing a considerable headache to the rest of the developers... any idea how this should be done?.
The working methodology that we are trying to implement is that only one developer (generally the leader of the project) can Commit the entire project but he must inform the rest of the team, so everybody can be prepared to receive a message asking him to discard his changes and read the new files from the repository.
I need suggestions or advice on how to handle a project with multiple developers using subversion.
We have read the Subversion handbook, and many other messages on StackOverflow but I still can't find any useful advice.
Thanks for any tip!
The reason the other guys are not seeing the changes is that they are not informed until they attempt to do an "update", "commit" or "diff" against the repository. SVN is a "pull" system, the repository doesn't inform the clients of anything without a command from them.
Communication is the key. If your developers are generally aware of what is going on in the project, or at least in their corner of the project if it's a large one, they'll minimize the risk of committing code that will upset the project.
Insisting that only one developer is allowed to commit to the repository is overkill IMHO and quite contrary to the whole idea of using version control. You might as well just have a single folder that only that developer can write to using a diffing tool each time.
Make sure your guys do an "Update", Compile, Test cycle before they "Commit". That way they are less likely to commit code that will break the build. If they're just a little careful, you'll all get the hang of it real quick, there really isn't that much to worry about. Good luck.
You are saying "The working methodology that we are trying to implement is that only one developer (generally the leader of the project) can Commit the entire project but he must inform the rest of the team, so everybody can be prepared to receive a message asking him to discard his changes and read the new files from the repository." Why is that needed? Are the other devs not able to checkin or not good enough to checkin code ? Sorry to say that in a drastic way: That's bull-shit. Every developer should be able to commit. If you like to separate the developers from each other you should use branches for this. And as already mentioned the communication is done by svn update/svn status -u etc.
Have someone used with success TRAC ticketing + wiki system accessing a code base residing in Perforce repository?
I've browsed in the TRAC related web sites and found this one, but the latest change on the page is something like an year ago, so I have concluded (correct me if I'm wrong) that the plugin is hardly in working state OR that for some reason there is no recent developments.
We are using Trac with Perforce, based on the PerforcePlugin you already mentioned. We have used the combination for about 1.5 years.
The plugin is basically stable enough for day-to-day work, but be prepared to fiddle with server memory allocation and have patience if working with large repositories. Also, it has some irritating bugs, and as you have already noticed, development seems to have stalled completely. In fairness it must be said that some of the bugs are due to shortcomings in Trac behaviuor and incompatability with "The Perforce Way".
Would I install Trac with Perforce again? Probably not. If forced to use Perforce, I would consider Redmine + Perforce.
Something else to watch out for on Trac-hacks is the quantity and content of the open tickets for the plug-in. The PerforcePlugin has a lot of open tickets.
This update may help you: http://lynxline.com/tracperforce/, people got it working okay with Trac 1.0