As part of my class, we have a project folder, and within it are individual files with a matching test file. When we download, that, we have to install npm, and as we finish each problem, we run mocha to test that our answers are correct.
Throughout, I would commit after each problem was solved, and then at the end, push it to a private github repo.
Now, I'm going back through the project, and I delete my answers so I can resolve them for practice, but running mocha doesn't work. Instead of seeing the 'passing' 'failing' in the terminal, I see the the console logs up to the problem I haven't done yet, which prints a reference error indicating I haven't declared the function (because I haven't reached that problem yet.
Other than deleting the code that I wrote, I've done nothing different, yet mocha won't work. Is there something else I need to do?
You're not giving us enough information to debug precisely what Mocha's complaining about, or enough information about your project so anybody could make any informed suggestions to help you.
No matter. SUGGESTION:
You're apparently using GitHub. Cool. Consider it your own little "time machine".
Save your current work. Either "git stash" (if you're comfortable with that), or simply back up your project folder to a temp directory).
Now revert back to a previous commit.
EXAMPLE:
git log # identify previous commits. Ideally, the last commit that "worked"
git checkout xxxxxxxxx # Check out out
Rinse and repeat until you find a commit that "works".
When you're done, you might wish to do something like this:
https://stackoverflow.com/a/21718540/421195
git revert --no-commit 0766c053..HEAD
git commit
This will revert everything from the HEAD back to the commit hash,
meaning it will recreate that commit state in the working tree as if
every commit after 0766c053 had been walked back. You can then commit
the current tree, and it will create a brand new commit essentially
equivalent to the commit you "reverted" to.
Git is your friend. It's useful as much more than simply a "source repository" to check in "completed code". You can also use it as a workaday tool for scenarios exactly like this.
Related
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.
is there a way to automatically update version number of a package.json (https://npmjs.org/doc/json.html) with the HEAD hash of git? I would like to have something like version: 1.0.0+rev82e4b91cfe42cd86e9453b4987b9cc446566de6 inside the project's package.json file. Eveything before the plus is set manually and the hash is updated everytime I commit something.
Is this possible? I couldn't find anything on this topic :-/
It appears that this can be done directly without a plugin. npm version $(git describe) will take the value from git describe and update the value of the version in package.json.
(I'm currently using npm version 3.10.)
Part of that can be solved with git-describe and there's actually a grunt plug-in that wraps that for you (https://github.com/mikaelkaron/grunt-git-describe/).
The second part you'd have to do manually (right now), but I actually have a similar problem at the moment, so I can try to hack up a grunt plug-in for you (and myself).
Full disclosure, I'm the author of grunt-git-describe above.
git rev-parse HEAD will write out the last commit to the current head branch which you could then append to a version number in your package whenever you run your build.
There are a number of git rev-xxx commands that might be useful for any additional stuff you might want to record.
Automatically at what point? Possibilities are:
Update the version field every time you run a build from a machine environment
Update the version field every time you run any build.
Update the version field in a git hook to keep in sync. Personally, I'd be nervous about a hook that performs a change when something changes. This strategy is highest risk, highest reward.
If you go with the first or second approach, it depends of course on what build tool you use. If you use grunt, see about a grunt plugin. I can't find any grunt plugins that do what you're asking for, but you can create one fairly easily.
http://gruntjs.com/plugins
If you do end up creating one, let me know as I am also in need of a similar process :)
In my case, I am using SVN, but want the same pattern. I want to put the SVN revision number as my build number.
My recommendation is to leave the build number blank in the file that is checked in and have your build environment do a git clone for a new build and update the build number. Then built packages always have something about them indicating the git commit they came from.
I think that for development, you don't really need it because you can always ask git which version you have checked out. There is a grunt-git plugin which you could maybe use to figure out the version in dev. (maybe git show?)
I've checked out a copy of the SVN branch (my branch) locally to which I've merged from a different branch (which has a completely different folder structure). So basically there are a lot of deletions (of old files) and additions (of new files).
When I try to commit the merge to the repository (to my branch), Tortoise says
This commit is not recursive, and there are moved/renamed folders selected for commit. Such moves/renames are always performed recursively in the repository. Do you want to commit anyway?
Is it fine to proceed with this commit? If not, what should I do so that there's no problem?
Also, for some files that I've added, I've made changes after adding (if this affects the nature).
Found by Google how to fix it: press F5 in the commit window (not in the "warning popup")
See http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2831045 for details.
On 26.08.2011 22:39, Ryan J Ollos wrote:
For several months now I've been seeing the following dialog box appear when
initiating Commit. It frequently happens when attempting to commit following
a merge.
The thing I have noticed lately however is that if I Cancel and then
manually refresh the file list (F5), I don't see the message again when
initiating the commit a second time. The commit seems to succeed fine and
with no further problems.
The commit dialog monitors the working copy in a background thread for
change notifications. Such notifications are sent by the OS in case
files are modified/moved/renamed/...
If such a notification is received, the commit dialog first does a few
checks so it can drop most of them. If the notification indicates that a
file that is not checked and not visible in the commit dialog has
somehow changed, it switches back to non-recursive committing.
That's because if you have e.g. a file open in another editor and save
your changes while the commit dialog is open, then that file would get
committed as well even though you haven't checked it in the commit
dialog (it doesn't show up until you refresh the dialog with F5).
So if you see that warning dialog often, please check if there's another
tool/app running which modifies files in your working copy.
And as you noticed: if you hit F5, that 'non-recursive flag' is reset
because after a refresh, you see all the files again - even the ones you
modified after you started the dialog.
Stefan
I had the same issue but resolved it by reverting changes to files that I had marked to 'ignore-on-commit'
Once I reverted these files, then tortoisesvn was able to commit all the other files from the merge
Is it fine if i proceed with this commit?
No, your commit will ignore all changes in WC-tree and reflect only root-level changes (broken merge).
You made an error when checking out non-recursive initially. You can try to perform good, full commit using --depth infinity parameter in the CLI or find this switch in TortoiseSVN GUI.
svn commit --depth infinity . -m "Merge"
Also for some files that I've SVN-added , I've made changes after adding (If this affects the nature).
In my case that was exactly what caused the message to appear, even I unselected those files for the commit.
Ugly solution which only works safely if just a few files are affected:
Create a copy of the changed files
Revert the changed files
Commit the merge/reintegration
Copy the changed files back to the original place
Reminder to self: only reintegrate a branch if the target (trunk) is clean.
I just had the same issue. Instead of selecting all the files, I clicked on versioned and everything worked well. In my case, the option versioned selected all the files, so everything is ok now.
It looks like TortoiseSVN performs some kind of validity checking before calling commit. Good but the error message is very unclear.
When I faced this issue, I went back to using the svn command line to commit. Commit failed due to the reason that one of the folders was not up to date. After updating just that folder, I ran "svn commit" once again and it went through.
Edit: PS: Before you use try this out, make sure you do not have any files marked as "ignore on commit". "Ignore on commit" is tortoise specific and SVN commit picks these changes as well.
Just thought I'd post this because it worked for me...
The reason this happened is because I'd partially renamed one of the new projects I'd created and for some reason they all showed up as "Missing" on the commit screen.
After I removed the project and folder (which SVN had put a tick on) and put it back in as a new project again, suddenly all of the "Missing" had turned into "Added" and the commit ran fine without warning me of anything.
Hope this helps!
I saw this issue and the cause was a few added files not having the added status for no apparent reason. They were 'normal' even though the parent folder correctly showed as 'added'. I reverted those 'normal' changes and then manually re-did them. This made each added item show up twice in the commit list but it resolved the error and everything appears to be in working order now.
It didn't have anything to do with ignore-on-commit as in another answer, it just seemed like a bug in TortoiseSVN.
The problem could be, that your mergeinfo is deleted by someone or automatically, because the infos moved up in the tree. If you are gonna merge them in again, it will work for the moment. But all others will get problems with their not merged branches. SVN will loose some code and merge already submitted code again.
So reverting those files and changing them again could work, but you should not just commit the changes.
i don't know a option for tortoisesvn but u could use the command line
svn commit --non-recursive [folder]
thats sould work just as u like it to work
greeings
My project directory inside trunk has been accidentally deleted by another user.
I can see my project when browsing it through the web at one revision (364), but the top of the tree it is missing (370)
How do I undo those commits and get my source tree back using the command line subversion client?
EDIT:
Thanks for all the hints. It was a combination of answers that helped me solve it. Although Avi's answer is the closest to the one that allowed me to restore the source tree. So I'll accept that. Although to be totally correct, below is what worked for me since even the trunk directory was eventually removed!
Final solution was:
svn cp https://xxx.xxx.xxx/url/trunk#364 https://xxx.xxx.xxx/url
I then checked this out locally:
svn co https://xxx.xxx.xxx/url/trunk
Copied my changes into this. Double check it builds without issues.
Followed by:
svn up
svn commit
You can copy it back to the current revision:
svn cp -r<revision where it existed> <project-url> <project-url>
EDIT:
Note that if you have changes to your working copy, you need to take care that they don't get overwritten when updating the working copy.
In this case, I suggest you copy them somewhere safe, then doing the svn cp I suggested above, and doing svn up to update your copy, before copying your local changes back in and committing.
svn up -r[revision]
Find the revision number first by doing svn log
I've been using SVN to track my projects, and I've run into a problem several times.
svn: Directory "/programming/projects/mydirectory" containing working copy admin area is missing
I bet you're familiar with that one. What seems to be making this happen is when I try to "svn add" a directory that I don't have write permission to. Instead of saying "you don't have permission to do that, try something else," SVN puts my working copy in a messed-up state where it can't be updated or checked in.
Why does it do that? That seems like the Wrong Thing. I've searched up ways to fix this (the simplest thing seems to be "svn --force delete mydirectory") but I'm still puzzled as to why SVN can put my working copy in a messed-up state instead of throwing an error message based on a very simple condition.
Basically, there are many many ways to "partially" mess up your working directory.
By experience, I've never reached a situation where I've been unable to recover and where I had to get local diffs, remove my checkout, recheckout, reapply, ...
By playing quite a lot with: svn cleanup, revert/update folders that are in "!", remove some messy stuff, revert some wrongful adds, you always get back on your feet.
This is obviously a disadvantage, because you have much manual fiddling to do, but on the other hand, it's probably better to always err on the side of caution: when something unexpected happens, just make sure disk state is consistent is recoverable and stop, let the user see what exactly is wrong, rather than risking to make a bad decision.
Why complaining about this here? Create a script, which reproduces the bug and post it to the svn users mailing list. Then maybe the bug will be fixed. Your chances are much higher than here on stackoverflow..
You can even say that you have contributed to the subversion project.