Version control on shared web host with Bazaar - linux

I have a project I am going to begin co-developing on one of my web servers. Due to the nature of this kind of thing I'd like to have some version control going on. I've been searching all day for something that fits my needs and Bazaar seems the way to go, but I cannot figure out how to configure it.
My web host is Linux, without SSH (or SFTP as far as I can tell). I've read that you can use Bazaar in this situation to make a "dumb" server, but I can't for the life of me figure out how to configure, or find a guide. Everything out there requires either SSH/CLI access (both of which I don't have) or are too vague to follow. I am using the Windows GUI for Bazaar as well.
Can anyone either point me to a guide/instructions on how to do it, or post one here?
Edit Since Original Post
I have been trying to do several things since my original post. It might be that I am misunderstanding how bazaar is meant to work. What I want is to have my php files etc. on my web host (to which i do not have ssh access) so that myself and codevelopers can edit and test files without overwritting each other.
I initially tried to "start a new project" on my server via "ftp://user:pass#server" and it says that is successful. Then it prompts with a "Unable to open location" error saying "C:/ftp:/user:pass#server is not a brand, checkout, or repository.
Do you want to open it as a virtual repository, searching for nested locations?"
When I hit yes, it gives me an error "Unable to change to C:/ftp:/user:pass#server - closing page."
if I do the same thing with the "Open an existing location" option, it gives me the same error, except afterwards the Bazaar GUI hangs with "Not Responding" and needs to be killed.
Either way nothing is created that I can then interact with in Bazaar. If I create a local project and then push, it all seems to work. However, if I try to commit changes so I can push them I get an error "Bazaar has encountered an environmental error. Please report a bug if this is not the result of a local problem at https://bugs.launchpad.net/qbzr/+filebug including this traceback, and a description of what you were doing when the error occurred." the show details says "bzr: ERROR: Unable to determine your name.
Please, set your name with the 'whoami' command.
E.g. bzr whoami "Your Name ""

Before you can commit revisions, you need to set a name and email address. These are important metadata in a commit. You can set these in the Settings | Configuration | User Configuration menu. On the General tab enter the Name and E-mail fields. It's recommended to use real data in public projects, so that others who view your project can contact you in case they have questions. But it doesn't have to be real. This is a one-time initial setup.
As a next step, I would do a test to make sure you can really use your server over FTP, as a sanity check:
Commit a few revisions in your local repository, just so that you have something to push. It could be anything, doesn't matter.
Try a push to a URL in the format: ftp://user:pass#server/absolute/path/to/somewhere. In the example in your post you wrote ftp://user:pass#server, but it's important to have an absolute path there, like in this example.
If for some reason the push doesn't work well using the GUI, try it on the command line, for example:
bzr push ftp://user:pass#server/absolute/path/to/somewhere
This should really give an error message we can debug. In that case, paste the output into your question.
UPDATE
You said in comments that something was wrong with your name+email setting, and changing that resolved the problem. It would be nice to know what exactly was the problem there.
About bzr push to an FTP server, I double checked, this will never create the files on the server. From bzr push -h:
The target branch will not have its working tree populated because this
is both expensive, and is not supported on remote file systems.
Some smart servers or protocols may put the working tree in place in the future.
Over FTP it's a "dumb" server, so it definitely won't put the files there, only the .bzr directory, which is the repository and branch data. If you want to have the files there, I'm afraid you have to copy manually. There is a related bzr-push-and-update plugin, but it requires ssh access, which is not your case.

Related

Bamboo 5.5.0 - How to delete a remote agent's capability via the bamboo-capabilities.properties file?

I am currently trying to automate the process of bamboo remote agent installation and uninstallation. I have run into a problem in regards to adding and removing capabilities.
What I am trying to automate:
(The following is what I do on the bamboo server via the GUI, I want to do this on the remote agent machine via bash script.)
I install the remote agent on a VM machine, then start it up. I go to the bamboo interface and click on the newly created agent's name.
I add a custom capability type, for the key I put 'buildserver' and for the value I put the name of the agent.
I add an 'Executable' capability of type 'Command' with Executable label 'cygwin' and path 'C:\cygwin64\bin\bash'
I navigate to the git executable, and remove it by clicking 'delete.' <--- (the problem step)
what I've done.
I have looked here and found a way to automate steps 1-3 using the following "bamboo-capabilities.properties" file:
buildserver="AGENTNAME"
system.builder.command.cygwin="C:\cygwin64\bin\bash"
However I am stuck on how I would remove the git capability (step 4.) I've tried something appending something like this to the file:
system.git.executable=""
but it does not seem to do anything. Does anyone know how I would do this? There seems to be very little documentation about this online.
Thanks very much.
I never found a way to get around this, but I found a workaround. I later learned the point of removing git in my situation was to allow a shared capability that was also called git to take precedence. My workaround was to set the non-shared capability to the value of the shared capability. I am not 100% sure that this does the same thing, and I am not in a position to test it yet, but as a capability seems to be only a key-value pair I don't see why it wouldn't.... will update if anything breaks.

Hgweb "Push" in IIS returning 502 (bad gateway)

I've got hgweb up and running on II7 7 (on windows server 2008). The web interface works, and I can view, pull, and clone the repositories there. But I cannot push, doing so gives me a 502 error right after "searching for changes". Using --debug shows the last few lines as:
sending unbundle command
sending 622 bytes
HTTP Error: 502 (Bad Gateway)
I am using TortoiseHG to push, but the result is the same when using the mercurial command line.
I had followed the tutorial here: http://www.sjmdev.com/blog/post/2011/03/30/setting-mercurial-18-server-iis7-windows-server-2008-r2.aspx to setup hgweb.
Looks like an old question but someone is bound to come across it again. I was close to drawing a black circle on a wall and ... anyhow the issue for us was the way central repository was created. We cloned it from BitBucket while being Remote connected to the machine as local administrator.
The issue was in [Repository].hg folder. You need to set correct permissions on it. Try it with adding Everyone -> Full permissions for test purpose. Please make sure you change this to a dedicated network login or appropriate local account afterwards.
I was seeing the exact same behaviour - even push worked fine with exception of getting a Bad Gateway after all the time. After correct permissions were set the issue was gone.
Thinking about it now, probably the best solution is to add each network login that uses the repo to machine users and then set up access permissions to .hg folder to local users.
Hope it helps someone.
Try using the ISAPI module method instead of the CGI that executes phython.exe as documented here. There's also another related, and possibly duplicate question here as well.
Take a look at the 'Push_ssl' setting in your hgweb.config file.
I was getting the same error (had mine set to '*'), and was able to resolve it by removing the line entirely. Granted, this makes Mercurial somewhat less secure, but it lets me get by the configuration issue (for now) while I investigate properly configuring SSL on the server.
You may also have to review the 'Allow_push' setting in order to get past further errors (or take another look at your authorization).
NOTE: At least in my case, having 'push_ssl = false' wasn't enough as that resulted in further errors (authorization failed).
(Again this is simply a temporary solution until the server can be properly secured.)
It could happen by different reasons, to get more details about the error run
hg push --config ui.usehttp2=true --config ui.http2debuglevel=info
For example, problem may occur because of proxy server or just in case when the Mercurial Web Server "forgets" about repositories it needs to serve: in case if you are using TortoiseHg workbench go to Workbench UI, Repository -> Start Web Server, make sure that your repository is in the list of the served repos.
Try use https instead http in .hg/hgrc, I have resolve this problem for code.google.com.
I had this issue, and the problem ended up being the server running out of disk space.

Getting to remote server from Dreamweaver CS4

All of a sudden, I'm getting the following message in the area where
my remote files used to be listed:
"To see the files in your repository you must define its Version
Control settings."
This is happening for multiple sites and the Version Control setting
is set to none (and it always has been).
I had another Dreamweaver author, try it on her system and she got to the remote server just fine. When I logged on to her system I got the same problem, but this time it said "FTP error...password problem..."--she's on Windows 7--I'm on XP. Our company does not support "version control." I can't find any "SVNs" lieing around either.
You will see this message when you are in the 'Repository View' and you haven't set up version control. You can check this in the FILES tab/window. If you don't see it press F8 or select Window/Files. Switch from Repository view to Local View, Test Sever, or Remote Server as appropriate.

Why does perforce show "//depot <contains no files or folders>"?

Starting yesterday I have been unable to connect to our Perforce server. Expanding the depot gives the message "//depot ". Funny because I connected just fine last week and the folks sitting next to me can connect without problems.
IT says nothing the settings have not changed and no errors are being reported. It doesn't help that IT is multiple time zones away!
I'm hoping someone here has seen a similar problem and can tell me which switch to flip.
SOLVED: Using P4Win or P4V there are no errors. BUT using the command line p4.exe I get the error "protected namespace - access denied". Passed this onto IT and perforce mysteriously works again. Sounds like I got my permissions disabled and then re-enabled. No-one has owned up to anything but at least I'm up and running again!
Funny that I had to go to the command line before I got an error message.
"protected namespace - access denied" - means you have no permissions for the specified path. You should see this message in P4V output window if you have the detailed logging enabled.
One possibility is an administrator may have accidentally introduced a typo in your username whilst editing a group or the protection table, or removed you from a group, essentially removing your access (but easy to restore). The spec depot keeps changes to perforce server control files so an administrator could check to see what went wrong, but the spec depot does not tell you which administrator changed it. The spec depot must be created before the event.

How to work collaboratively on a website

I'm working on a website with some other people. Usually when we want to modify something, we do the change on our machine and just upload the new version with ftp, hope it'll works (or that nobody will notice it doesn't the time we correct it) and that's it.
It's already not the best way to work alone but even less to work collaboratively so I'm asking advices.
I think that a solution like svn/git/mercurial could help me. I found bitbucket which allows free private repository with mercurial. But still after, how can I upload the changes I did to the ftp and make sure the version I've on my computer is the same than the one on the server.
We are all doing it during our free time (not paid) and some people comes and leave every year so I'm looking for something free, easy to use (explain to everyone why we should use a DVCS is already hard) and which doesn't rely on a specific person.
The server we are using to host the website is a cheap one and doesn't allow the use of ssh, svn,...
Thank you
Version control will not help with the issue you are describing - namely, uploading untested changes to a production site.
What you (and your team) need, is better quality control procedures - you need a test website and a tester (QA) person. The process would be:
Make a change
Update the test website
Have the update and the whole website signed off by QA
Update the production/live site
What you will gain by using version control (CVS, SVN, Git or anything else) is recoverability - you will be able to go back to a version before any breaking change. It will still not solve the issue of "the new code broke the site".
You want scheduled releases.
Commit and update code regularly
Code freeze or develop in a branch and merge to the trunk
test on a staging environment
Find a bug goto step 1
Release
You need to understand that what represents your latest correct working build is not what's on the server but in your source repository whether that be SVN or just the file system. Anything as long as it isn't the live server! Make sure everything works locally as expected then unless the site is huge (I guess not given your situation) deploy it in its entirety as a single version.

Resources