I have a bash script that works at the moment. It gets an image and JDK 8 from a link and then runs a installer for the JDK 8 to move on to setting up another piece of software.
As I was debugging the script, I kept finding myself having to delete directories and even the java installation because when I introduce a fix and rerun the script, I have to wait for everything to download again and I have to worry about duplicate files messing up my current logic -which can probably be improved, but I'll go to the StackExchange Code Review site later.
At the moment, I would like to know what approaches there are to prevent commands -like downloading the JDK and running the JDK installer script all over again and others- from running again.
What kind of general approaches are out there for cases such as these?
For the JDK download and running the installer, I did think of simply checking for the existing of java on the system and if there is then bash would not not to run those commands.
However, there are other commands I do not want run and I do want to simply check, for example, the existence of certain files to prevent wget-ing them all over again and moving them -causing duplicates. (Should I maybe suck it up and do that anyway as that might be best practice?)
I did also think of perhaps, at each successful command, outputting like a 1 to a text file and mapping each line in that text file to the commands run in the script (like using an if statement to see if that command had a 1 or not in the text file) and if it was a 0, then the script would know only to run that command and never the 1s.
That sounded clunky to me and I am pretty sure that is not a good approach.
My primary development environment is within Windows but for Git, I try to mainly use the command line for doing most things and occasionally use TortoiseGit for others (such as viewing viewing logs or rebasing). Usually when switching branches, there are no problems when it's removing and restoring files. But certain programs lock these files (e.g., editing CSV files in Excel) which causes minor issues when switching branches.
If switching from the command prompt and a file is locked, it'll simply notify you that it was unable to unlink the file and ask you if you want to retry. This will give me a chance to close the program that has the lock and let it try again.
switching from command prompt
However, if I were to switch branches through TortoiseGit, it will have the error but will act as if the response was N and finish up leaving the files in their current state. It gets a little annoying as I have to go back and manually revert the files. I'd rather have it wait and ask me to try again, like it usually does with other actions.
switching from TortoiseGit
Is there any way I can force TortoiseGit to halt and ask me to retry unlinking the file when switching branches? Or is this just not a feature of TortoiseGit?
Up to TortoiseGit 2.2.3 the yes/no question wrapper (GIT_ASK_YESNO) was not implemented. Starting with 2.2.4 this will be supported, however, I don't know why after an "error" success is reported by git.exe.
When I try to launch GitHub for Mac it immediately starts using up all of the free memory (as much as 1.6 Gb) until the application freezes. How can I limit the memory usage for this app?
I saw a previous stackoverflow post (titled 'Memory Issues for Mac App') that touched on this issue, and I've updated my .gitconfig file, but it isn't having any effect. It's not clear if if the app is even reading the config file or how it would be possible to determine whether it is or not.
Any suggestions?
My suggestion for git is to use it from the command line. It was designed for use from the command line. By not using it from the command line, you lose the following:
command history
scriptability
piping
tab-completion
lots of help and examples online
The first is a big one. You will ask yourself "What did I do to create a branch with tracking of another one?". On the command line you can hit ctrl-R and type "branch". Hit ctrl-R a few more times to iterate over each occasion that you used git branch. You will find what you did when you made that branch. Pressing up and down arrows will scroll you through previous and subsequent commands that you issued. You can even add the time and date into history and when you list the history you can see exactly when you did something.
Scripts are very useful for things you do repeatedly and the same tasks are tedious when done manually through the gui.
Piping is very useful as you can alter results from one command and pass them to another. Something I do quite often is
git branch |
grep 'filter for what I need' |
sed 'some funky transformation' |
xargs -n 1 -i{} git push -u centralrepo {}:public/{}
It's a made up example of how you might string together a few commands to automate some very time consuming task.
Tab-completion is great as it saves you time for having to hunt around for what branch exists or what file exists. It is context sensitive so when git expects a file to be listed, tab will fall through and start matching files underneath. When it's expecting a remote name, hitting tab a couple of times will get you a list of remote repositories. Partially typed branches or files or remote will get you a subset when you hit tab twice.
Getting help with git is important. It's got a steep learning curve. The majority of git's use is from the command line. So when you run into issues, google is very good at finding a solution quickly. Other git tools don't have this luxury and you may find yourself wasting quite a lot of time to find answers.
I working on a company machine and cannot change the name of the windows username. I am running TortoiseSvn locally and I would like to change the commits to my name. I do not want to right click each commit and manually change the names. Is there a way to do this? I know that there are a couple of threads about this but there are no solutions.
Yes, there is a way to do it, but you probably can't.
In Subversion, there are two types of properties: File properties that are revisioned with the file itself, and Revision properties that are attached not to a file, but to a revision. These are not versioned.
There are several standard revision properties:
svn:log: This is the commit comment.
svn:author: This is the user who made the commit.
svn:date: This is the date and time stamp of the commit.
You can change any of these revision properties with this command:
$ svn pset svn:log --rev-prop -r193 "The commit comment for revsion #193 is this!"
It would be fairly simple to write a script in PowerShell or Python or Perl to do this to a whole bunch of revisions at once. However, you can imagine what type of havoc this could wreck if you could change the date, authorship, and commit comment of any Subversion revision at whim.
Therefore, in order to be able to use a rev-prop change, the repository must have a hook to allow you to do this. This is the only case where you must have a hook to explicitly allow a permitted action. And, of course, it is highly doubtful that you will have the ability to create such a hook.
Now, I'm assuming you were talking about already committed revisions. If you are sharing a working copy, and you make changes, and then commit those changes along with everyone else, you're using Subversion all wrong.
Each user should have their own working directory where they can make changes. This way, the repository will record who did the commit without any shenanigans.
If you simply want to checkout from the repository with a name other than your Windows name, you can save your authentication on your local machine, and Subversion will use that authorization when it does checkouts from that repository.
I believe that authorizations are stored under the %HOMEPATH%.subversion\auth directory. It shouldn't take too long to find the file with the authorization and delete it. Then, when you checkout the next time, you need to specify the user and password and save the credentials. After that, that's what TortoiseSVN will use by default when you use that repository.
That's three different answers covering three different situations in using Subversion and credentials. If I didn't answer the correct scenario, edit your question and explain exactly what you mean and what you want to accomplish. The situation you describe isn't very clear.
How do you store file permissions in a repository? A few files need to be read-only to stop a third party program from trashing it but after checking out of the repository they are set to read-write.
I looked on google and found a blog post from 2005 that states that Subversion doesn't store file-permissions. There are patches and hook-scripts listed (only one url still exists). Three years later does Subversion still not store file permissions and are hooks the only way to go about this? (I've never done hooks and rather use something that is native to Subversion.)
SVN does have the capability of storing metadata (properties) along with a file. The properties are basically just key/value pairs, however there are some special keys like the 'svn:executable', if this property exists for a file, Subversion will set the filesystem's executable bit for that file when checking the file out. While I know this is not exactly what you are looking for it might just be enough (was for me).
There are other properties for line ending (svn:eol-style) and mime type(svn:mime-type).
There's no native way to store file permissions in SVN.
Both asvn and the patch from that blog post seem to be up (and hosted on the official SVN repository), and that's a good thing, but I don't think they will have such metadata handling in the core version any time soon.
SVN has had the ability to handle symbolic links and executables specially for a long while, but neither work properly on Win32. I wouldn't hold my breath for another such non-portable feature (though it wouldn't be too hard to implement on top of the already existing metadata system.)
I would consider writing a shell script to manually adjust file permissions, then putting it in the repository.
One possible solution would be to write a script that you check in with the rest of your code and which is run as the first step of your build process.
This script runs through your copy of the codebase and sets read permissions on certain files.
Ideally the script would read the list of files from a simple input file.
This would make it easy to maintain and easy for other developers to understand which files get marked as read-only.
Since this wasn't fully said in previous responses yet. I hate to resurrect zombied threads though.
Since adding permission support for SVN would have to accommodate multiple OS's and permission types, NFS, POSIX, ARWED, and RACF
This would make SVN bloated, possibly clash with conflicting permission types like NFS and POSIX, or open up possible exploits/security vulnerabilities.
There are a couple of workarounds.
pre-commit, post-commit, start-commit are the more commonly used, and are a part of the Subversion system.
But will allow you to control the permissions with what ever programming language you like.
The system I implemented is what I call a packager, that validates the committed files of the working copy, then parses a metadata file, which lists out the default permissions desired for files/folders, and any changes to them you also desire.
Owner, Group, Folders, Files
default: <user> www-user 750 640
/path/to/file: <user> non-www 770 770
/path/to/file2: <user> <user> 700 700
You can also expand upon this and allow things such as automated moving, renaming them, tagging revision by types, like alpha, beta, release candidate, release
As far as supporting clients to checkout your repository files with permissions attached to them. You are better off looking into creating an installer of your package and offering that as a resource.
Imagine people setting their repositories with an executable in it set with permissions of root:www-user 4777
This is the updated link for SVN patch which handles unix style file permissions correctly. I have tested out on fedora12 and seems to work as expected:
I just saved it /usr/bin/asvn and use asvn instead of svn command if i need permissions handled correctly.
Many answers have stated that svn does not store file permissions. This may be true, but I was able to solve a dll file without execute permissions problem simply by these steps:
chmod 755 badpermission.dll
mv badpermission.dll ../
svn update
svn rm badpermission.dll
svn commit badpermission.dll -m "Remove dll to fix permissions"
mv ../badpermission.dll .
svn add badpermission.dll
svn commit badpermission.dll -m "Add the dll back to fix permissions"
rm badpermission.dll
svn update
badpermission.dll comes back with execute permissions
#morechilli:
The asvn wrapper from my earlier post and the blog in the OP's post seems to do what you're suggesting. Though it stores the permissions in the corresponding files' repository properties as opposed to a single external file.
I would recommend to generate permissions map using mtree utility (FreeBSD has it by default), store the map in the repository, and, as was mentioned above, run a script that would restore proper file permissions from the map as the first step of the build process.
Locking would not solve this problem. Locking stops others from editing the file. This is a third party application which gets run as part of the build process that tries to write to a file - changing it - which breaks the build process. Therefore we need to stop the program from changing the file which is simply marking the file read-only. We would like that information to be held in the repository and carried across checkins, branches, etc.
Graham, svn doesn't store permissions. Your only option is to wrap your call to svn in a script. The script should call svn with its arguments, then set the permissions afterward. Depending on your environment, you might need to call your script svn and tweak your PATH to ensure it gets called.
I quite like morechilli's idea to have the list of files and permissions checked into the repository itself.
We created a batch file to do this for us. Would prefer actual support in subversion though...
Consider using svn lock to disallow others from writing to the file.