I'm adding a snapshot of a stream to a repository workspace.
How do I load the snapshot components into the repository ?
Currently I just have the repository workspace with the snapshot, but the workspace should also contain the components of the snapshot.
To add the snapshot to a repository I use :
scm snapshot promote -r <repositry url> <repository workspace> <snapshot>
Perhaps I should be using a different scm command to add the components of a snapshot to the repository instead of the snapshot itself ?
I used the '<repository workspace name' & 'snapshot name'. I did not need to use their id's.
No error is returned and I can view the created snapshot :
But the components for this snapshot are not added to the repository workspace.
I think ive solved this. Running the command (includes --stream parameter) :
scm create workspace -r <repository url> <repository workspace> --stream <stream name>
Creates the workspace & adds components to this newly created workspace. These components in the just created workspace have the same baseline as defined in the stream.
What you did was to create the snapshot on the stream (in order to link all the components)
When you add a snapshot to a repo workspace, you do a promote of the snapshot:
scm snapshot promote -r <repositry url> <repository workspace> <snapshot>
that you mention should work (not sure if you need the id of the repo workspace, and the id of the snapshot through)
Actually, Ralf Hohendorf commented that this command (scm snapshot promote) only moves the snapshot from a stream to the repository workspace.
The snapshot will not be used, only moved.
The idea though is to populate another empty stream, in order for a repo workspace to reflect the list of components.
If the components are already on the stream, then as the OP mentions, this is enough:
scm create workspace -r <repository url> <repository workspace> --stream <stream name>
No need to create or promote a snapshot in that case (since the stream already reflect the components you want).
You should see in the "Component" section of your workspace those components.
Note that you will still need to load that repo workspace in order to see the files on your disk.
Related
I followed the instructions at https://create-react-app.dev/docs/deployment/#github-pages and noticed that the command gh-pages -b master -d build replaced the contents of my working directory with the contents of the build folder and committed these changes to the master branch. This works as advertised to publish my React app at myusername.github.io, but it makes it impossible to make further changes to the source files since they are no longer available in the working directory.
I understand that GitHub project pages work differently than GitHub user pages (they allow the application to be published from the gh-pages branch rather than master). So, do I have to move my code to a new project repository or is there a way to accomplish the same thing using my existing user repository?
You can maintain your repositories code on the master branch by changing the repository settings on Github, for Github Pages, use the /root directory and select a new branch other than master, then, also change your deploy script.
Optionally, for a custom domain built using create-react-app, you will need to and a CNAME file to the your apps public directory.
Github Pages Settings:
Github Pages settings using branch named production
Add optional CNAME file:
Add CNAME file to public directory for custom domain
Change the script to point to the new branch. In your package.json file update master to the name of your new branch.
Change:
"deploy": "gh-pages -b master -d build",
to:
"deploy": "gh-pages -b production -d build",
Where production is the name of your new branch.
There's no need to move the code. Simply create a new branch called source (or dev, or whatever you want to call it) from the commit just before gh-pages' first "Update" commit, and use that branch, rather than master, to continue development.
I've switched to windows and am having a hard time using bitbucket with it.
Within the downloads menu you can add files but this is not added to source.
I've also tried using source tree (web application) but when I attempt to push the files they do not exist in my directory. Any idea how I can do this or a guide which explains how to upload files. It's been a number of years since I have used bitbucket on windows.
Bitbucket is simply a git provider. You'll have to use Git commands (or a GUI like Sourcetree, Gitkraken, etc.) to push (upload) your files to source.
A basic guide to working with Git can be found here.
Windows or Linux only you need a git console or git cli installed in your default cli.
First clone your repository to your local system. Go to your
bitbucket account and your repository need to be file uploaded. Copy
the git url command. Open git console and type the following command.
git clone "git URL"
Explore you repository and make changes. Like add file which you want to upload to it.
Go to your git console again and type the following commands.
git add .
git commit -m "commit message like - adding file"
git push origin master
I'm new to JavaFX 8 and the IntelliJ IDE. I have a JavaFX8 project that works but not as I would like. I'd like to try another approach but the substantial changes may not work. I don't want to loose code I have working.
To save code I have working, I've been creating a new project and then locally copying all the folders(.idea, out, src) and files except .iml, of the working project into the appropriate folders in the new project with the newly generated .iml.
This always seems to work but is it proper procedure?
I'm not on a team of developers and have yet to learn Git/GitHub.
Please advise. Thanks.
Maybe you should learn how to use a Version Control System like Git, then you can create a project repository and have different branches for things you want to try out. Keeping the working code in your master branch will prevent you loosing your working code. Also, when using a vcs you can always revert to versions of your code that have been working. The IntelliJ Idea IDE has perfect support for working with all different types of version control systems. If you don't want to learn any forms of vcs then there is no other way to "backup" your working code.
Is it proper procedure? It's probably not how most people would go about achieving what you want to achieve but it's certainly workable. If you wanted to stick with that for simplicity now, I'd copy the whole directory structure, delete the .idea and .iml files, and then create a new project in IntelliJ on that clean copy: IntelliJ will automatically set up folder structure based on the existing source without you having to go through any additional manual setup.
If you're willing to experiment with the git route, to achieve the basics of what you want to achieve is not very complicated and I've written a small quick-start below. IntelliJ offers very good support for Git, and once your repository is created you can do everything you need from the IDE. I'm going to assume you're working on Windows, although the steps shouldn't be too far removed on other platforms.
Install Git
You can download and install Git from https://git-scm.com/download/win, which will install a command shell called Git Bash.
One-off setup for your project
Open up git bash and go into the directory containing your source. Rather than seeing separate drives as Windows does, Git Bash assumes there is a logical 'root' directory under which all your files are accessible. Your C: drive will be /c. To move around you can use cd to change directory (using / instead of ) and ls to list files instead of using dir.
Assuming your source code is in C:\projects\myproject:
cd /c/projects/myproject
git init
The second line above creates a git repository in that directory. This doesn't affect your code, it just creates a folder called .git that contains all of the book-keeping information.
You don't want to have every file under version control - in particular you don't want your build outputs. You need to set up a file in your project directory called .gitignore which tells git which files and directories should be ignored. As a starting point you can copy https://github.com/github/gitignore/blob/master/Java.gitignore and rename the file to .gitignore
Basic Commands and committing your initial version
There are a small number of basic commands:
git status
Running git status will tell you which files have been modified, which are not under version control, and which files have been added to the staging area to be committed next time.
git add path/to/file
This adds a file to the staging area waiting to be committed. You can add multiple files to the staging area before committing them in one go.
git commit -m "description of your change"
This commits all of the staged files as a new version, which the specified commit message.
If you go into your project directory, do a git status and check through the list to make sure there's nothing you don't want to have under version control, then you can do git add . to add everything to the staging area and git commit -m "Check in initial version of the source code" to commit it to the repository.
After you've committed, you can run
git log
To see a history of all of the changes. IntelliJ has a view that will show you the same thing.
Creating an experimental branch
This is where git shines; if you want to try something experimental you can create a branch of your project while allowing git to preserve the original version.
git checkout -b experiment1
Will create and switch to a branch called experiment1. You can delete, rename, move, rewrite and develop whatever you like on this branch. The changes you commit will be independent of your original working version.
You can switch back to your original version (preserving all of the changes you've committed on that branch) using:
git checkout master
Where master is just the name of the default branch created when you ran git init. The experimental version will still be there and can be switched to again using git checkout experiment1 or from IntelliJ using the branch selection in the bottom right corner of the status bar.
If you decide that the changes you've made in experiment1 are to become your new "good" version, you can merge them back into the master branch and repeat the cycle from there.
My group is developing code for use internally as well as to be provided to an external (offsite) group. A baseline version is delivered externally via tar files, but incremental changes (every week or two) are provided with bzr patch files using the "bzr send" command. I've got a bzr repository for development and when a baseline is sent out, we create a reference branch to capture the as-delivered configuration. When a patch file is generated, the reference branch is used as the target for the send command, then the patch file is sent to the external site. My problem is this.... The app I'm developing to automate this process checks consistency between the parent and submit branches as shown with the bzr info command. If the reference branches move due to disk reorganization, the path to the parent will likely not be correct because the branch.conf file uses relative paths to the parent when the branch is created. Is there a way for bazaar to save the path to the parent branch as an absolute path in the branch.conf file?
You can modify the path in branch.conf to be an absolute path (URL) and Bazaar should happily handle that.
Setting the path can either be done by editing it with your favorite editor, or using the command:
bzr config --scope=branch parent_location=URL
I accidently removed a hosted snapshot repository from Nexus containing a few artifacts needed by other developers on my team. Fine, I'll be able to recreate it fairly easy, but when I tried to add the repository again with the same name as the one I removed, the "Upload Artifact" tab did not show. I tried to clean the cache and reindex the public and public snapshot repos, but that didn't help. I also tried setting an alternative storage path by entering an alternative path on "Override Local Storage Location", same result.
Will I have to create a brand new repository with a different name and change all repository reference in my projects?
Thanks,
David
You should be able to create the new repo without any problem. It's possible you where inheriting permissions to this repo via a group and when you made the new repo you didn't add it to the group.
Also, all delete operations in Nexus simply move files to the sonatype-work/nexus/trash so you could have just copied all those files back directly on the disk after recreating the repo.
I think I noticed that snapshot repositories do not have the Artifact Upload tab, so possibly you created it as a snapshot repo?