Jump to content

Should I avoid DropBox?


mawg

Should Plastic SCM be used with DropBox?  

1 member has voted

  1. 1. Should Plastic SCM be used with DropBox?

    • Dude, stay away from that. Here be dragons
    • Put your working code under DropBox, but not your client
      0
    • Put your data and the client program under DropBox
      0


Recommended Posts

Until now, I have been using DropBox to synch my work between my home & office PCs (I have my own small company), with a good backup system which saves daily, weekly and monthly. My DropBox has a parturition with the same Windows drive letter and folder structure on both PCs.

 

Obviously, while that is better than nothing, it is not good enough, so I am startng to use Plastic (chosen over Subversion because of its GUI - way to go, guys!).

 

Anyhoo, my question is whether I should continue to use DropBox, now that I use Plastic.

 

Something intuitively says no, but I can;t figure what. It seem to me I don't really want to check in when leaving the office for home & vice versa, but only when I have a stable version. But, still I get a nagging doubt, which is why I am asking here.

 

Do you think it is good practice for me to only check in a stable build which passes unit tests and to have my checked out, under development s/w synched by DropBox, so that I can go from home to office & back and continue working on it (so long as I close the IDE before leaving, of course)?  I should point out that I am the only one who works on the code (told you it is a small company).

 

So much for the code. Is there anything to gain by putting the Plastic SCM program in DropBox? I can see that there would be if it saved its data in an .INI file (is that an option? Portable Plastic SCM? It would be nice to to have on a thumb drive). Of course, if configuration data are stored in the Windows registry then there is nothing to gain.

Link to comment
Share on other sites

Hi mawg!

 

I understand your workflow and why you think you should keep using DropBox and Plastic SCM at the same time.

 

My answer depends on one thing: Do you have access to the Plastic SCM from both home and office locations?

 

If the answer is yes you should only use Plastic SCM.

If the answer is no you should use both.

 

If you don't have access to the Plastic SCM server from both locations is pretty handy to use Dropbox since the code will be downloaded automatically, that's why if you have access to the Plastic SCM server the same thing can be achieved with the SCM.

 

Regarding if you should only commit stable points, NO!!! :) Plastic SCM encourage the commit operation plus the branch creation, we call it "branch-per-task" methodology, and believe it's useful even for a standalone developer. Check this out -> http://www.plasticscm.com/infocenter/technical-articles/kb-branch-per-task-workflow.aspx

 

Committing only the stable point generates a poor history repository with only the big milestones, it's better than nothing of course but you can take advance of Plastic SCM and create a richer history. The milestones will remain as the stable point to deliver and they should be labeled using the Plastic SCM labels.

 

Regarding putting Plastic SCM inside Dropbox, I rather prefer to prepare a USB with a portable edition of Plastic SCM, it's perfectly doable, even more some users are currently enjoying it! -> http://www.plasticscm.net/index.php?/topic/992-portable-repositoriesserver/

 

Hope it helps!

Link to comment
Share on other sites

I forgot to say that there's a small point that can brake your Plastic SCM workspaces if you put them in Sync with dropbox. :P Small big detail.

 

There's a hidden ".plastic" directory inside the root level of your workspace path, it contains important information about the status of your workspace, the files that are inside the .plastic directory are evolving meanwhile your workspace does. It's dangerous to add this directory to dropbox, let me give you an example.

 

Every time you perform and update or commit operation, for example, a small "plastic.lck" lock file is created. It prevents from performing another operation meanwhile the first one is still running. Imagine that in that moment the dropbox daemon enters and adds the "plastic.lck" file into the dropbox repository. From that moment your workspace will be always locked due to dropbox will continue downloading over and over again that file....

 

The same happens for the "plastic.changes" file that is in charge of tracking all the changes inside your workspace (Checkouts, moved, deleted files...). There're a few more that are affected.

 

So my recommendation is if you are using dropbox to have the Plastic SCM workspace synced please remove from the dropbox control the ".plastic" directory.

Link to comment
Share on other sites

Hi mawg!

 

I have been there. I know what you're going.

My tip (even if the plastic guys dont like it) is: avoid copying the folders. 

Many explained it very well :P

 

I follow the below script to keep my plastic instances " in sync" when I can't do that via normal path:

 

  1. find out what is your repository file using the command in prompt: "cm lrep". Your file will be the "repo_X" where X is the number displayed by the repository's name side;
  2. stop the "Plastic Server 4" process on the "services.msc";
  3. copy the repository file as shown in the step 1;
  4. copy your file to a pendrive (or dropbox);

When you're at home or any other machine with plastic, do this:

 

  1. stop the "Plastic Server 4" process on the "services.msc";
  2. copy the repository file from the pendrive (or dropbox folder) to the plastic server folder on your installation;
  3. start the "Plastic Server 4" process;
  4. Update your workspace and be happy!

Seems complex but with a few times doing it, it becomes "automatic" :)

 

Hop it helps!

Link to comment
Share on other sites

Thanks for the feedback, guys.

 

Since I have access to the PlasticSCM server from all locations, I will use PlasticSCM only and move my code out of DropBox.

 

I will also force explicit checkout of files, in case I forget & start working at 2 locations. Will "merge" is a very powerful thing, I'd rather not use it at all (weeell, _maybe_ after branching).

 

In general, I have projects which I can only work on in the office (because they interact with some special hardware) and some more lightweight/almost hobby projects (or prototypes) which I work on at home. For me, personally, it will be easy to split my projects into two groups; it might not be so easy for others.

Thanks again, I have barely begun with PlasticSCM but am already impressed with it - and with the forum :-)

Link to comment
Share on other sites

  • 3 weeks later...

I forgot to say that there's a small point that can brake your Plastic SCM workspaces if you put them in Sync with dropbox. :P Small big detail.

 

There's a hidden ".plastic" directory inside the root level of your workspace path, it contains important information about the status of your workspace, the files that are inside the .plastic directory are evolving meanwhile your workspace does. It's dangerous to add this directory to dropbox, let me give you an example.

 

Every time you perform and update or commit operation, for example, a small "plastic.lck" lock file is created. It prevents from performing another operation meanwhile the first one is still running. Imagine that in that moment the dropbox daemon enters and adds the "plastic.lck" file into the dropbox repository. From that moment your workspace will be always locked due to dropbox will continue downloading over and over again that file....

 

The same happens for the "plastic.changes" file that is in charge of tracking all the changes inside your workspace (Checkouts, moved, deleted files...). There're a few more that are affected.

 

So my recommendation is if you are using dropbox to have the Plastic SCM workspace synced please remove from the dropbox control the ".plastic" directory.

 

I am wondering - should I give myself one User for each PC which I use?

 

That way, if I start working on some code at the office, when I go home if I want to work on it I will be branching and will have to merge later.

 

If I only have one User, I would probably lose the changes from the office when I got home.

 

I am beginning to think that I should only work on each project in one place, to avoid confusion.  Then I could have two users and give reporitory access rights to either the home or the office user but not both.

 

I wonder what others do ...

Link to comment
Share on other sites

RIght now, it is me & one other guy with a single repository.

 

I want to add a few more respositories and allow two others access to them. So, 2 groups and I am a member of each group.

 

My point is that before now I used DropBox to synch * woudl strat working on something in the office, then go home & work more, then back to the office & work more ....

 

Sinc ewe agree that I should forget DropBox, I am wondering how best to proceed.

 

I think maybe I should separte projects into office or home and only work on them in one place. If I do, it's probably a good idea to have 2 different users and access rights for each.

 

What do you think?  This is more a "use case" question than technical

Link to comment
Share on other sites

Don't you have an accessible machine with a Plastic Server that can be used from the office and home? That will help you life a lot! :)

 

You can use your home computer opening the router port....

I think there's a very small linux instance in EC2 that is free: http://aws.amazon.com/free/faqs/ You can setup a Plastic Server there and it will be always online.

Link to comment
Share on other sites

Another idea, which I use personally, is you can create a repository on bitbucket.org and create a private repository (Bitbucket lets you have up to 5 for free).  Then you can donwload the latest version of Plastic from the Labs (4.2.something) and use the GitSync functionality to keep all the machines in sync with Bitbucket as your "shared server".

Link to comment
Share on other sites

I think that my post was not clear, sorry guys. I should have said that I have 3 machines. One server in the office, where PlasticSCM runs, one desktop in the office and one laptop at home.

 

But my main question now is how many PlaticSCM user Ids I should have?.Only one, or one for home & one for office? That way, if I accidentally edit code in both locations it will be branch & merge. But if I have only one user Id and make different edits in 2 locations, I fear that the first change will be lost(?).

 

I think maybe I should separate projects into office or home and only work on them in one place. If I do, it's probably a good idea to have 2 different users and access rights for each (both with read access, but only one location with write access for each project)1

 

What do you think?.

Link to comment
Share on other sites

Hi folks,

 

We're working on an Azure based Plastic SCM server.

 

It has been under tests for months, since it required several changes on the server code. In fact we're using the same server process you run on your machines but heavily modified to:

 

  • Support the Azure SQL Server backend (which was very interesting to adapt).
  • Able to start up as an Azure worker (not a difficult change).
  • Be ready to handle multiple workers using the same databases (same repos). This is one of the biggest changes since Plastic SCM caching was not cloud oriented. This is the part we've been working on for a while.

So we expect to open a "beta" in the coming month or so. Initially a closed one and then we will be opening up.

 

Our goal is not having some sort of "github" because we understand we're in a very different business.

 

It will be more oriented towards commercial teams working on different offices, typically small teams who won't be setting up a corporate server and will rely on the plastic "cloud" service to host their shared repos.

 

In fact, we are testing an encrypted replication which is able to push data "encrypted" to the cloud server so it can only decrypted by servers owning the right keys, so that you can securely push to the cloud because even is someone manages to pull your code, he wouldn't be able to decrypt it (not ourselves either).

 

We'll keep you up to date.

 

Also, meanwhile, for people who don't want to have a central server, why don't you setup a virtual network with something like https://secure.logmein.com/products/hamachi/ ?

Link to comment
Share on other sites

I think that my post was not clear, sorry guys. I should have said that I have 3 machines. One server in the office, where PlasticSCM runs, one desktop in the office and one laptop at home.

 

But my main question now is how many PlaticSCM user Ids I should have?.Only one, or one for home & one for office? That way, if I accidentally edit code in both locations it will be branch & merge. But if I have only one user Id and make different edits in 2 locations, I fear that the first change will be lost(?).

 

I think maybe I should separate projects into office or home and only work on them in one place. If I do, it's probably a good idea to have 2 different users and access rights for each (both with read access, but only one location with write access for each project)1

 

What do you think?.

 

Hi mawg,

 

Ok, you don't really have to worry about the user id.

 

If you're working on the same repository from the two computers (home and work) you will have two workspaces (your copies on disk to work with the code).

 

But whenever you checkin changes (whether you're using user "mawg" or "mm" or whatever) the system will take care of them and you'll never loose them. The system will ask for merge if the changes collide, so don't worry about the user id.

 

 

pablo

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...