I've successfully copied the most current version of a project from GitLab into my Jupyter notebook using the git clone command in the Linux terminal. Let's say the project contains a Python program called python_code.ipynb.
I've already made edits to an earlier version of python_code.ipynb and named it python_code_myversion.ipynb.
Newbie question: How do I overwrite python_code.ipyn with python_code_myversion.ipynb so I can then git push my changes back to Gitlab project? I'd prefer to do this rather than manually rewrite my code edits in python_code.ipyn.
Generally the point of source version control is that you edit the actual files you want to work on, rather than manually creating a copy of them.
In any case, to go back to this workflow to achieve what you are trying to do with your question: it will vary depending on which Operating System you are on. As the python_code.ipynb is already under version control, you can essentially delete it and rename the python_code_myversion.ipynb to replace it. On Linux, you could do this in one go with this command:
mv python_code_myversion.ipynb python_code.ipynb
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 did a temporary solution for a small continuous integration with shell script.
It updates from svn and then copies files to site's root directory.
So it looks like this
cd ...
update svn
cp -R ... ...
And then put it in crontab.
Well, it works fine for temp. solution, but it would want to make some improvement and to define somehow that svn was changed (new revision appeared) and only in this case to copy files (well, its connected with every-minut copying files makes server work slower).
But im a mean user of linux :(
So the question is:
how to define, using bash script, that svn got new commits and only in this case to make an update and other stuff, like copying files.
You can do 'svn info' in the directory (and use awk|grep|your favorite tool) to extract the revision number of what you've checked out. Do the same to the location you copy to. If the revision number in the checkout directory is higher than the one in the destination directory, then do the copy.
That's assuming that you copy everything including the .svn directories.
If you exclude them, then you should 'svn info' before you update, and again after, and compare the two revisions.
Stop.
Why in the world would you do this?
With eighty totally free, super easy to install, CI tools out there, why in the world would you start hacking your own together with shell scripts and cron?
Unless you're looking to work on your scripting / cron skills and want to use building your own CI as an fun little scenario to play through, you're just wasting your time here.
After few weeks of struggle i am able to create a medium native package debian package which works well in installation and removing of the package.
As http://www.quietsche-entchen.de/cgi-bin/wiki.cgi/-wiki/CreatingDebianPackages
Debian wiki
http://wiki.debian.org/HowToPackageForDebian http://www.debian.org/doc/manuals/maint-guide/ these are the quite good material for beginners,
I have basic problem, in updating the package all the files data.tar.gz are updated by default.
I want only few files to get updated in the data.tar.gz based on a key variable stored in all the files.
After the unpacking that is executing preinst script, all the files in data.tar.gz are already updated..
my idea was to take back up of the files intially before upgrading the package, and check key variable in files.. if the key variable is greater than the current variable replace it..
which means i am writing a simple backup script.. and executing in the postinst file..
i donot think this is good idea.. and more over limitations in dash script make it a very tough job..
What are you trying to accomplish here? During the reinstallation (or upgrading) of a Debian package, replacement of all of the non-conffiles with the latest version is exactly what's supposed to happen. If the file hasn't changed since the last installed version of the package then there's no harm in updating it anyway, and if is has changed, it's supposed to be updated.
If you have specific files which might be modified by the user and should be preserved across upgrades, make then conf files. The package system will prompt the user and ask them if they want to keep the package maintainer's version or the locally modified version.
(But if you're going to make every file a conf file, then you're probably doing something wrong.)
To make a file a conffile, list it in debian/conffiles. But if the file is going to be installed under /etc then you don't need to do this because dh_installdeb will do it for you.
EDIT following additional information in comment:
Suppose you have files test1.sh and test2.sh (among others) in your package. In the Debian world, they are either conffiles are intended to be modified by the end user, or they're not.
conffiles should be relatively few in number and as short as possible, to minimize the burden of having to reconcile changes made by the package maintainer with conflicting changes made by the end user.
If there are things mixed into the code that the end user is likely to want to tune, try to factor them out into a configuration file. If you put that file in /etc, you don't even have to manually designate it as a conffile.
If the end user needs to make a change to a non-conffile, they should use the dpkg-divert protocol to (1) move the original file aside, and (2) edit a copy. Diverted files are respected by package upgrades. The end user who uses dpkg-divert should be aware that things might break after upgrades as a result, because the package maintainer hasn't foreseen that these files would be modified by end users and the locally modified version might be incompatible with a newly upgraded version of a different file. dpkg-divert should be used carefully and sparingly.
I have a settings file that is under version control using subversion. Everybody has their own copy of this file, and I need this not to be ever committed. However, like I said, there is already a copy under version control. My question is: how do I remove this file from version control without deleting everyone's file, then add it to the ignore list so it won't be committed? I'm using linux command line svn.
Make a clean checkout, svn delete the file and add the ignore. Then commit this. Everyone else will have to take care (once) that their local copy isn't deleted on the next svn update, but after that, the local file would stay undisturbed and ignored by SVN.
If you remove the file from version control, how does a developer new to the project (or the one who accidentally deleted his local copy) get it after initial checkout? What if there are additions to the settings file?
I would suggest the following: Keep a default settings file (with no passwords, hostnames, connection strings, etc.) in SVN, name it something like settings.dist, and let the code work with a copy of this, named settings. Every developer has to make this copy once, and can then work with her personalized settings. If there are additions, add them to settings.dist – everyone else will get them with a update and can merge then into her personalized copy.
After you delete the file, your users will have to recover the file from the repository using svn export.
$ svn export -r x path ./
Where x is a revision where the file existed before it was deleted, path is the full path to the file, and ./ is where the file will be placed.
See svn help export for more information.
simply define a file containing settings that will override the default ones. This file is not checked into Subversion and each developer is responsible for maintaining this file according to their environments.
In an Ant-based world, you would have the files:
settings.properties
settings-local.properties (ignored for Subversion)
and in your build.xml file
<property file="settings-local.properties"/>
<property file="settings.properties"/>
For those who couldn't connect the dots:
modify the build.xml file like proposed
set the setting-local.properties as ignored
in an init target of your build, copy the settings.properties to settings-local.properties
wait a couple of days until everyone had the chance to run this target
delete the setting.properties from Subversion
Voila, every developer has its own setting-local.properties and everything was done automatically (and no developer lost his or her settings, which happens if you brutally delete the file from Suvbersion and there is no "Everyone else will have to take care...")
I have a similar issue. In my case it's an auto-generated user settings file (visual studio) that was accidentally checked in very early in the project. While just deleting it might work, it seems more correct to have it removed from the history, as it was never supposed to be in there in the first place.
I came across this, which might be a new feature since this question was originally posted 7.5 years ago:
https://stackoverflow.com/a/6025750/779130
Seems like an idea would be to:
1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.
This might be the only way to completely get rid of the file. In most cases the "delete and ignore" approach might be good enough.
[[ I'm new to subversion, so maybe this doesn't make sense. marking this as wiki -- if you know the right answer, please APPEND in the later section ]]
Couldn't you have a custom set of checkout steps so each user gets a different settings folder?
$ svn checkout http://example.com/project project
..
$ dir project
original_settings\ folder1\ folder2\
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\ folder1\ folder2\ settings\
Or for new users
$ svn import project\settings http://example.com/project/aaron_settings
What I'm getting at is you want each user to have a custom view of the repository. In other version control systems, you could set up a custom listing of which projects you were using and which you weren't and which you put in odd places.
Does this work in subversion? The above code looks really risky, but maybe i'm doing it wrong.
WIKI:
(nothing yet)