so I just downloaded plastic scm for my unity project today and whenever I try to checkin my changes (I have made a lot of progress on the game, so my guess is that the mass checkin is the problem) I get this error saying: "this is usually a temporary error during hostname resolution and means that the local server did not receive a response from an authoritative server" for completely no reason, if you know how to stop this from happening, please answer my question
1- Plastic SCM error whenever I try to checkin
2- Full Window screenshot
Most of the time that error is related with network issues (Slow, unstable, high latency), you might want to consider a distributed workflow in that case: https://www.plasticscm.com/book/index.html#_centralized_distributed
A workaround is to checkin smaller chunks at a time until everything gets uploaded.
Related
Long story short: Overleaf keeps returning: "Sorry, there was a problem checking our GitHub service. Please try again in a few moments." when I "Pull GitHub changes to Overleaf".
In details: I have used git to control versions of coding line on my laptop. These lines of code are stored in private mode on GitHub. Then, I have pulled these codes to my Overleaf account (I have Premium account with Overleaf), i.e. in Overleaf: Menu --> GitHub --> "Pull GitHub changes to Overleaf".
This way has been working well until I came across this error very recently: Sorry, there was a problem checking our GitHub service. Please try again in a few moments.
I have tried following the given instruction many times, e.g. by waiting and retrying after every hour and repeat the same thing on the next days. This error, however, still keeps showing up. Besides, I have also checked internet connection, just in case, both at home and at University. But both are still okay and there is no problem with internet signal. I am not very sure anymore what I should do next. Perhaps do you have any idea?
I've been trying to work with github-linguist for a while and it still gives a bit of problem.
After a few days of trying to figure out different issues with the language statistics, I managed to set .githubattributes with the right commands to get the correct statistics from github-linguist command:
But in GitHub's webpage/server it's still not showing up:
This is the link to the repo I am working on: https://github.com/FeriBolour/cotton-phenotyping
I tried different solutions:
Waited almost a week.
Pushed meaningless stuff to the repo to update the server.
It's still not working. What do you suggest me to do.
It could be two things:
It's not computing statistics on the branch you expect. GitHub only displays statistics for the default branch, but I believe locally you can compute statistics for any branch.
There's a bug on GitHub's side that caused the statistics update to be cancelled. I've seen that happen before while working on Linguist. I suspect it happens when the statistic-update job queue grows too large and jobs are dropped.
In your case, it's not problem 1 because you appear to have only one branch on this repository. It's most likely problem 2. You can contact GitHub support and they should have a way to manually trigger a statistic update for your repository.
I am very confused about how this all works, so I am gonna make a series of questions.
So I am almost at the end of my final degree project and I have been using Github for version control. At some point, I had to store large files (>100mb) and got this message:
My first question is: what does actually happen if I click "commit anyway"? does it mean that I can't commit anymore?
Anyway, I have done research about lfs and eventually installed it in my repo (btw, this is a Unity project). I have followed this video: https://www.youtube.com/watch?v=09McJ2NL7YM&t=615s. This guy suggests using this custom .gitattribute: https://gist.github.com/nemotoo/b8a1c3a0f1225bb9231979f389fd4f3. This automatically tracks all files with a certain extension and pushes them in lfs. At the time I thought this was cool, until I realised that this file made me push all tracked files no matter how big or small they are. what I should have done is use bash for pushing to lfs only when I would get the message above (so only for files >100mb). Since my whole degree depends on this project, I did not want to mess with GitHub and spend time trying to "fix it", but I want to know if there is any way to restore the whole history and made it as I have never used lfs (?)
Lastly, since I got loads of files stored in lfs, I get that whenever someone re-clones my repo, can just do git lfs fetch --all and then git lfs pull (and this should use up my bandwidth, right?). But.. what happens if someone decides to just "download" the project ("download zip)? Well, I have tried it, and all those files are missing completely.. Is there a way to download the project with the original files instead of pointers?
Also, if you exceed the free 1gb data pack that GitHub provides, and stop paying for additional storage, do you lose all those files??
At some point in the future, I would like to remove lfs, and if I have to, only store files >100mb (I think they are just 2 in total). But would that still mean that to have a complete version of the project the only option would be to clone the repo instead of downloading (?).
Sorry for the long question but I really need to understand these things.
We are working on a single project, and also committing code at the end of day on SVN so that can get all update project. But issues is very often our code getting errors while committing code and projects get empty if someone get update at that time. So my question is are there any set of rules which we've to follow on committing so that every one go on straight path and no one get in trouble and save a lot time from these errors.
Thanks in advance. Cheers
Search Google, something similar to "source control best practices".
Top result has several tips. Sounds like the biggest problem you're facing is integrating with others' changes. Perhaps look into the following sections:
Incorporate others' changes frequently
Share your changes frequently
Coordinate with your co-workers
Investigate why you get errors. Blind application of rules is not good.
For example:
person A committed a code producing compilation error
why?
he finished his task, but hasn't checked build before committing to the trunk
why?
the entire build it too slow
solution: speed-up build, set up continuous build system which will check every commit and notify developers about problems as soon as possible
Another example:
person B committed a code which breaks the build
why?
he wanted to store his changes, but the task is not finished
solution: advice him to create a branch, when the task is finished it can be merged to the trunk (if branch lives for long time, merge changes from trunk to it periodically, then the merge will not be a problem)
There possible other scenarios. With more details you will be able to ask more precise question on StackOverflow and get better answers.
In case of use of SVN co-ordination is must between the team.
Make sure whenever you commit the code you have a idea about what are you committing.
The golden rule is "One developer One class".
If at all two different developers are working on same class. Ask them to maintain a document on what changes they have made. And, most important to mark a comments in a class it self.
There are some important things which need to be followed while committing the code. Whenever you see a conflict in your local files and server files. Make sure you go through every conflict and select the appropriate action.
Understand one important thing, whenever SVN is used one persons mistake can affect everyone.
Whenever possible, don't edit the same line of code as someone else
Leave meaningful comments on your commit messages
Comment your code
Make sure that all the code you commit compiles and runs as it should
Commit when appropriate ie: are passing off part of your code to be used by others or are done working on a feature
Make sure to communicate with other team members
If you find code that you don't know what it does, ask the author
If you're making major changes that will take a while to implement, use a branch and then merge it back in
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.