Anyone out there using LiveCode in a multi developer project?
Either way, can someone recommend a good source control system / plugin to use?
We've looked at MagicCarpet but since it is no longer developed we wish to use something else.
Thanks
I'm working on a solution to this problem by exporting the stack file as a structured directory of script, json and image files which will diff and merge nicely in most VCS. It is not yet available but the intention is it will be open source. My goal is to demonstrate it at the RunRevLive conference in May.
Here's the repo for lcVCS https://github.com/montegoulding/lcVCS
I have put a git library stack on revOnline (libVersionControl) that exports to structured xml files that git can handle. It works as far as it goes, but I have hopes that Monte's solution will supersede this effort.
revOnline link to stack
Yes, our team has been using LiveCode with multiple developers. Since the Livecode community is still young, acquiring good source control tools can be a challenge. Our solution has been to break code into modules (stack files). When there are updates to merge into the main codebase, we clone our existing codebase, and merge code changes manually using line by line compare in a text editor. This is not a fun process, but is much less painful than it sounds.
If I were to redesign the system, we would simply use Git (Github.com etc.). There is no reason this would not work with Livecode stacks.
We use LiveCode in a small team with Subversion.
We don't have a perfect solution, but it is very lightweight; we all use a custom extension to the standard toolbar, which among other things has a 'save+backup' button. When we started using it with Subversion, we added code to this button which saves an XML sidecar file for the stack. The file contains all the scripts, custom properties, and optionally fields (controlled by user property in each stack). In our case almost all of our work is in scripts, so this works for us.
The effect is that each time we commit to SVN, we're always committing two files, the LiveCode stack and the accompanying sidecar file - the latter works fine for diffing etc.
Where this lets us down is that we don't have any solution for merging. If we were working on larger systems more actively, we'd also modify I expect look to modify the sidecar format into a complete folder of files. For now however this makes the situation workable (and it takes no noticeable time to generate the sidecar file).
Happy to share code if that was useful.
I know of a tool thats being worked on that is going to really help in this regard. When he showed it to me it looked very functional already. But I'm not sure when he will share it with the community.
So the point is, its just a matter of time before people's stuff comes together to make a turn key solution for this.
I'm currently working on a project that's been going on for several years straight. The development-team is small (less than 5 programmers), and source-control is virtually non-existent, and the deployment-process as is is just based on manually moving files from one server to another. The project is in classic ASP, so building isn't an issue, as both deployment and testing is just about getting the files to where they need to be and directing the browser at the correct location. Currently all development is done on a network-drive which is also the test-server. The test-server is only available when inside the the local network (can be accessed trough vpn), and is available on the address 'site.test' in the browser (requires editing to the hosts-file on all the clients, but since there are so few of us that hasn't proven to be any problem at all). All development is done in visual studio. Whenever a file is change the developer that changed the file is required to write the file he changed into a word-document and include a small description as of what was changed and why. Then, whenever there's supposed to be a version-bump (deployment), our lead-developer goes trough the word-document and copies every file (file by file) that has changed over to the production-server. Now, I don't think I need to tell you that this method is very error prone (a developer might for instance forget to add that he changed some dependency, and that might cause problems when deployed), and there's a lot of work involved with deploying.
And here comes the main question. I've been asked by the lead developer to use some time and see if I can come up with a simple solution that can simplify and automate the "version-control" and the deployment. Now, the important thing is that it's as easy as posible to use for the developers. Two of the existing developers have worked with computers for a long time, and are pretty stuck up in their routines, so for instance changing it into something like git bash wouldn't work at all. Don't get me wrong, I love git, but the first time one of them got a merge-conflict they wouldn't know what to do at all. Also, it would be ideal to change to a more distributed development-process where the developers wouldn't need to be logged into vpn (or need internet at all) to develop, and the changes they made offline could be synced up when they were done with them. Now, I've looked at Teem Development Server from Microsoft because of it's strong integration with Visual Studio. As far as I've tested it seems possible to make Visual Studio prompt the user if they want to check in changes whenever the user closes Visual Studio. Now, using TFS for source-control would probably eliminate most of the problems with the development, but how about deployment? Not to mention versioning? As far as I've understood (I've only looked briefly at TFS), TFS has a running number for every check-in, but is it possible to tell TFS that this check-in should be version 2.0.1 of the system (for example), and then have it deploy it to the web-server? And another problem, the whole solution consists of about 10 directories with hundreds of files in, though the system itself (without images and such) is only 5 directories, and only these 5 should be deployed to the server, is this possible to automate?
I know there's a lot of questions here, but what is most important is that I want to automate the development process (not the coding, but the managing of the code), and the deployment process, and I want to make it as simple as possible to use. I don't care if the setup is a bit of work, cause I got enough time at hand to setup whatever system that fits our needs, but the other devs should not have to do a lot of setup. If all of the machines that should use the system needs to be setup once, that's no problem at all, cause I can do that, but there shouldn't bee any need to do config and setups as we go.
Now, do any of you have any suggestions to what systems to use/how to use them, in order to simplify the described processes above? I've worked with several types of scm-systems before (GIT, HG and SubVersion), but I don't have any experience with build-systems at all (if that is needed). Articles, and discussion on how to efficiently setup systems like this would be greatly appreciated. In advance, thanks.
This is pretty subjective territory, but I think you need to get some easy wins first. The developers who are "stuck up in there ways" are the main roadblock here. They are going to see change as disruptive and not worth it. You need to slowly and carefully go for the easy wins.
First, TFS is probably not going to be a good choice. It's expensive, heavy, and the source control in TFS is pretty lousy. Go for Subversion: it's easy to setup and easy to use, and it's free. Get that in place first, and get the devs using it. Much easier said than done.
Later (possibly much later), once the devs are using it and couldn't imagine life without a VCS, then you could switch to Hg or Git if you need first class branching and all those other nice features.
Once you have Subversion in place, you can use something like JetBrains TeamCity or Jenkins, both of which are free and easy to use. However, I'm just assuming you don't have a lot of tests and build scripts that the CI server is really going to be running, so it's far more important that you get VCS first. In all things: keep it as simple as possible. Baby steps. Get some wins, build trust, repeat.
I can't even begin to think where to begin with this! Intending no offense directed at you, apart from the mention of git and HG, this post could have been written 10 years ago.
1) Source control - How can a team of developers possibly work effectively without some form of source control? Hell, even if it's Visual Source Safe (* shudder *) at least it would be something. You have to insist that the team implement source control. You know what's available so I won't get into preaching about that. (However, Subversion with TortoiseSVN has worked quite well for me.)
2)
"write the file he changed into a
word-document and include a small
description as of what was changed and
why"
You have got to be kidding... What happens if two developers change the same file? Does the lead then have to manually merge two changes that s/he extracts from the word doc? Please see #1 and explain to them how commit comments work.
Since your don't really need to "build" (i.e. compiled, etc.) anything, you should be able to solve most of your problems with some simple tools. First and foremost you need to use a source control solution. Yes, the developers would have to learn how to use another tool (EEEK!). You could do the initial leg work of getting the code into the repository. If you have file access to the other developers machines, you could even copy a checked-out working copy to their machines so they wouldn't have to do the checkout themselves (not really that hard). You could then use all the creamy goodness of version control to create version branches when each deployment needs to be done. You could write simple scripts using the command line SVN tools to check out said branches and automatically copy the files to the target server(s). Using a tool like BeyondCompare, the copy process could be restricted to only the files that are different (plus BC can handle an FTP target if that is an issue). By enforcing commit comments on the SVN repo, you'll guarantee that the developers provide comments, and for each set of changes between releases you could very easily generate a list of all those comments using the CSM log retrieval features.
I'm looking for a subversion tool, and i have the following requirements:
Must integrate into VS 2008
Automatically submits new versions
Does not use the command line as primary interface
Doesn't clutter up explorer with bright icon overlays or context menus
is only going to be used by one user mostly if not completely, so doesn't need to have advanced diff tools or anything like that
Basically, i want a subversioning tool that will only bother me when creating a project or actually needing to get something from a previous version.
Does something like that exist, and if so, what is it?
Yes. VisualSVN (commercial)
Except for "automatically submits new versions" - that makes no sense.
The day computers know when your code is ready to be committed and free of bugs is the day the world needs a lot less programmers
You commit when you're done a task, which effectively gives you a rollback point. It's also important to add a meaningful commit message ("Fixed crash when clicking on Save button") - this way you can find things easily later. A lot of new users to version control skip this part, and unfortunately only learn the hard way 3 months later when they need to go back and undo a fix/feature.
AnkhSvn is a free alternative, I've personally only used 1.x, which was really quite terrible. It definitely looks more usable in 2.x.
One upside to VisualSVN is that it uses TortoiseSVN for a lot of its dialogs. This means when you're working with subversion just from explorer, you have basically the same interface and same UI. Quite handy, as it lets you do things like edit images or text files without having to fire up VisualStudio, or edit scripts/installers, or other parts of a product that are not necessarily in VisualStudio.
Yes, they are available.
The two I know of are VisualSVN and AnkhSVN. There are a bunch of comparisons available on SO
I use AnkhSVN myself. It is free, integrates nicely with Visual Studio, and doesn't cause any performance issues.
visual SVN is what you need.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I read all over the Internet (various sites and blogs) about version control. How great it is and how all developers NEED to use it because it is very useful.
Here is the question: do I really need this? I'm a front-end developer (usually just HTML/CSS/JavaScript) and I NEVER had a problem like "Wow, my files from yesterday!".
I've tried to use it, installed Subversion and TortoiseSVN, I understand the concept behind version control but... I can't use it (weird for me).
OK, so... Is that bad? I usually work alone (freelancer) and I had no client that asked me to use Subversion (but it never is too late for this, right?). So, should I start and struggle to learn to use Subversion (or something similar?) Or it's just a waste of time?
Related question: Good excuses NOT to use version control.
Here's a scenario that may illustrate the usefulness of source control even if you work alone.
Your client asks you to implement an ambitious modification to the website. It'll take you a couple of weeks, and involve edits to many pages. You get to work.
You're 50% done with this task when the client calls and tells you to drop what you're doing to make an urgent but more minor change to the site. You're not done with the larger task, so it's not ready to go live, and the client can't wait for the smaller change. But he also wants the minor change to be merged into your work for the larger change.
Maybe you are working on the large task in a separate folder containing a copy of the website. Now you have to figure out how to do the minor change in a way that can be deployed quickly. You work furiously and get it done. The client calls back with further refinement requests. You do this too and deploy it. All is well.
Now you have to merge it into the work in progress for the major change. What did you change for the urgent work? You were working too fast to keep notes. And you can't just diff the two directories easily now that both have changes relative to the baseline you started from.
The above scenario shows that source control can be a great tool, even if you work solo.
You can use branches to work on longer-term tasks and then merge the branch back into the main line when it's done.
You can compare whole sets of files to other branches or to past revisions to see what's different.
You can track work over time (which is great for reporting and invoicing by the way).
You can recover any revision of any file based on date or on a milestone that you defined.
For solo work, Subversion or Git is recommended. Anyone is free to prefer one or the other, but either is clearly better than not using any version control. Good books are "Pragmatic Version Control using Subversion, 2nd Edition" by Mike Mason or "Pragmatic Version Control Using Git" by Travis Swicegood.
There are lots of benefits, yes you need it.
What tools/techniques can benefit a solo developer?
Best Version control for lone developer
You don't need version control any more than a trapese artist needs a safety net. It's like backing up your hard drive—most of the time it seems redundant as nothing happens but it will be needed eventually. There's no maybes here. It will happen. And you can never predict when and the past is a poor indicator as to when it will happen. It may happen only once ever in the future but even if you know it'll happen once you won't know how bad it will be.
Yes!
Do it. It won't hurt you..
I usually switch from Laptop to PC and back and it's absolutely great to have your code somewhere in a central repository.
Sometimes it's great to go just revert to the latest revision because you screwed up something that would be too difficult to fix..
The biggest advantage that is missing is being able to re-produce the source code that generated an old build.
At build time, you tag the source control with 'Build 4.26'. The next day you start coding Build 4.27. Three months later, when a client says, "I'm using Build 4.26, and there's a bug in the Frickershaw feature. I can't upgrade to any other build because of some changes to file formats you made in build 4.27. Is there anything you can do for me? I'm willing to pay."
Then, you can checkout a branch of the 4.26 source code... fix the Frickershaw feature, and then re-build the package for the user in about an hour or two. Then you can switch back to version 4.39, and keep working.
In the same vein, you can track down the exact point at which a bug was added. Test versions 4.25 for the bug, then 4.20, then 4.10 and eventually find the bug was introduced in version 4.12. Then you look for all changes made between 'Build 4.11' and 'Build 4.12', and then focus on the Frickershaw feature. You can quickly find the source code for the bug without ever debugging it.
Branching doesn't seem useful to you? Have you never wanted to just try something out to see if it would work? I do a lot of plain old html/css stuff too, and I find that invaluable. There is literally no danger in branching to test something, seeing if it works, and deciding "meh" and then just rolling back.
I've never needed to get to a backup (knock on wood), but I find just the rolling back functionality invaluable.
A few perks as a freelancer:
Know definitively what you changed in every single file and when (as long as you check in often)
Rollback to any version in your past. Surprising how often this is valuable.
Track a set of changes as a 'release'. This way you know what each client is currently using and what's in development.
Backup
The ability to easily share a project if you suddenly aren't solo
Try a DVCS like Git or Bazaar. They are incredibly easy to set up, easy to use, and offer all the important features of Subversion, CVS, etc.
The key is that you can revert back to a working version when you break something, which is often much faster than undoing the change manually.
I wouldn't hire a contractor without them integrating into our processes. They would have to access code via our SVN, and would be unlikely to get paid without meeting unit testing and code review requirements.
If contracting I'd make sure to have solid experience of both VSS (check-in/out) and CVS (merge & conflict) models.
Working on your own you have a great opportunity to play and learn with the latest - I'd be trying out Git.
As a lone developer you can think of source control as an unlimited undo - one that works across sessions and reboots.
A minor advantage of source control for me is that I work on multiple development computers. It is easy to move my work around between machines.
The greatest advantage in my opinion has already been listed. It allows me to sleep at night knowing that if we have to roll-back a change it will be fairly easy.
I think the main advantage in moving from a "keep-all-versions file system" to a source code control system lies in the fact that the sccs adds structure to all those versions you kept of all those files, and provides you with records of "what was the consistent state of the whole file system at point X".
In other words, "Which version of file A goes with which versions of B, C, D, ...".
And an afterthought (¡!): the special act of committing or checking in makes you think about "what is this?", and the resulting log message can, hopefully, serve as memory...
The literal answer to this question is, No, you do not NEED version control.
You do, however, WANT version control, even if you don't know it.
That said, many SCM tools can be mysterious or downright unpleasant to use until you break through the Grok Barrier, so let's revise that a bit:
"You do, however, want EASY-TO-USE version control." And it's out there...download a bunch of recommended visual clients and give them a whirl, then try whichever maps best to the way you think.
Which leads to the question you meant to ask:
Why do I want to use version control?"
Answer: Version control allows you to be FEARLESS!
Yes you need it.
At the very least, for a single developer shop, you need to move code into a ProjectName-Date-Time directory several times a day.
That is, write a script that will automatically back up your working directory at lunch and at quitting time, without overwriting other back ups.
This can grow pretty fast, so eventually you'll want to save only the differences between files, which is what a VC application does.
Since you usually work alone, I would say that it is a good idea to use version control. One of the main benefits I have found in using version control (Subversion in my case), is that when working alone it gives me more confidence in trying a new approach to the problem. You can always branch to a new method or framework of solving the problem and see if you like it better. If it turns out that this branch doesn't work, you can just abandon it and go back to the old method. This also makes it easier to try out the different solutions side by side.
So, if you have ever seen a different approach to solving a problem and you wanted to try it out, I would definitely use version control as a tool to make this easier.
If you are working on your own, and are performing backups on a regular basis, VC may not be needed (unless you count your backups as version history). As soon as you start working with another developer, you should get version control in place so that you don't start over-writing each other's work.
Even if you don't need it right now, it is something you will need whenever you work in a team.
Having a history of changes to your html/css/javascript can be a godsend. Being able to compare your front-end to the code a month, or several months ago can really go a long way in figuring out why suddenly the template is all askew.
Plus if you ever want/need to get help on your project(s), you'll have an easy system to distribute, track, and deploy updated content.
Definitely do it, you'll thank yourself once you get used to it.
Checkout (one time)
Update (beginning of day)
Commit (end of task/change after testing)
That's all there is to it. Don't commit EVERY single modification that you're refreshing in the browser, just the one's you want to go live.
Think if it like a backup. It is a little irritating until the day you need it. Then the amount of work you lose is directly proportional to the frequency of your backups.
Another benifit is being able to look at old ways you did things that may have become obsolete in a certain spot but could be usefull in another. Just cut and paste the old code that you got when doing a compare.
That is unless you like reinventing the wheel you already reinvented...
When things can go wrong they will.
It is very nice to have the ability to reference code you may have deleted a month ago, or to recover the entire project after a hardware failure or upgrade.
There may also be a point in the future when the project is worked on by more than you. The ability to prevent (or control) branching and versioning is a must in an environment like that.
Must must must must must must. You must use version control.
This is of the deepest importance.
If you don't understand why now, you will one day.
When your client phones up in a panic because something is broken on the live site and it's a regression, you'll be glad you can just open TortoiseSVN and see what it was you did last Tuesday that caused the breakage.
It's really odd. Ever since I started using version control, I've very occasionally had the need to look up old copies of my code and use them. I never needed to do this before...probably because the idea of doing didn't really stick. It's easy not to notice those times when you could have found version control helpful.
Search within an entire codebase. It's a killer feature, mainly because the search gets actioned on another machine so you can get on with your work undisturbed.
Which incidentally, is the reason why we didn't change to SourceGear Vault. It can't do this. We're still looking for a SourceSafe-compatible replacement for... well, SourceSafe. Despite what everyone says, it hasn't let us down yet*
* this may just be a matter of time.
I think you've made the right decision to use some kind of version control. For simplicity, I'd go with SVN (ignore CVS as SVN is basically a "better" CVS)
SVN can work with "local" repositories right on the filesystem and on lots of platform so you don't have to bite off too much in infrastructure (servers, networks, etc)
Great resource for SVN: http://svnbook.red-bean.com
I don't know much about GIT, but it being open source and gain lots of mindshare probably has alot of similar advantages!
Borrowing a quote from somewhere: You might not need it now, but when you do, you'll be glad you did.
Happy versioning!
Although old and crude, we have found Microsoft Visual SourceSafe to work. It works great for keeping version history. If you are not to worried about branching, which being the solo developer you may not, it might just fit the bill.
As far as checking in, finding a good checkpoint can be a challenge, but checking in on every save will only make versioning hard to track.
"Do I really need version control?"
Yes. Unless you write perfect code that never needs to get changed.
An example:
I had a requirement. I built up a webpage, spent a day or so on the page, it's Section 508 compatibility (this was about 6-7 years ago), and uploaded to the website. Next the requirement was changed drastically. I spend another day working on the page (and Hayuge Excel files didn't convert into accessible HTML easily). About a week later, client switches asks that we go back to Version A. Source control would have done this in about 10 minutes. As it was, I had to blow another %$#^^&$# day on the task.
Yes, you need version control either for development purposes or simply for storing your documents. This way, you can go back in time if you're required to do so in order to revert changes or mistake made on a code or documents.
Once you start working on a team that references ever upgrading "components" from multiple callers/applications, version control will be an absolute must. In that environment, there is no way that you can keep up with all the permutations of possible change.
You need version control just like you need insurance in life.
You need version control to manage different file versions. With it, you can get and work on the files from different places and it facilitates team members to collaborate on the same project.