So my desktop is my primary workstation for VS2008 that's supported on the backend by TFS. I'm hitting the road for a week and I'd like to take a project with me. I'd like to checkout the entire project, copy it to my external HD and then work off that. I know that when I try to open it on my laptop that won't be connected to the network, I'll be asked to remove the source control bindings. So do I do that, and then when I come back to the office just copy all the files on top of my checked out version? I just don't wanna mess anything up. :)
You can take your TFS solution offline on your Desktop Machine. Then you copy the working directories onto your laptop (assuming your laptop has VS and everything else set up) it will allow you to continue working.
When you get back, you copy your Laptop solution root folder over your Desktop solution root folder, and then take the solution back online. Depending on the size of your solution, this might take some time, because it will do a file-by-file comparison to see what was changed (it will do this only against the files that you changed on the road, because your solution in an 'offline mode' will still keep track of which files were changed). Then a list will appear in your pending changes. You can check each of those (as you normally would) before checking them in.
You could use SvnBridge and get it out into a svn repository, and then do whatever you want with it because svn handles working offline really well, and then check it back in when you're done.
Since you have VS2008, this should mostly be handled for you. No need to make extraneous copies.
Here's a click-by-click walkthru of the new offline feature: http://teamfoundation.blogspot.com/2007/12/offline-and-back-again-in-vs2008.html
If you want to manually manage the offline state, Ben Ryan has several instructional posts: http://blogs.msdn.com/benryan/archive/2008/07/09/using-tfs-2008-power-tools-to-modify-server-s-offline-state.aspx
Checkout the entire project if you can.
Don't remove the source bindings
Before you check-in make a copy of your local source just to be safe.
Related
I have a dev folder with all my projects. Some of these are on github and some are not. I also use Dropbox (with symlinks) to keep my data synchronised across several computers.
For example if I add something to my Documents folder on one PC I can then see it in the corresponding folder on another PC.
My question is: If I do the same with my dev folder (so the dev folder is synced by Dropbox on both PCs) will it cause problems with my pushing to github?
You don't ever want to mix code versioning strategies. Either all of your code lives in git (which is a good idea), or it all lives in Dropbox (which doesn't give you any history, hence a very bad idea).
When you add a source file to git, you should be forced to push it to Github so it can be pulled at a later date.
I get the feeling that you will run into issues when pushing the code - you'll be adding new files in through one source, but pulling through another - it'd turn into a headache more than a benefit.
I'm not sure exactly how you could "prove" that is ok. But, I have used exactly this development model with no issues. I personally, don't use symlinks in my dropbox but that shouldn't affect anything. All of my git repos are on my Dropbox. I've been working this way for over a year across OXS, Windows, and Ubuntu. All of my commits and pushes have worked just fine.
Also, this may be a repeat of this question: Using Git and Dropbox together effectively?
[edit:]
Actually one thing was recently brought to my attention is that you might run into an issue with line endings across systems. This post from GitHub (with a link back to an SO question) explains how to deal with line endings.
I had the same question and now my answer is "simply move your repository out of Dropbox".
As you can see, Using Git and Dropbox together effectively? is not the same question, but if you just search the key word "GitHub", you will see the debate about your confusing. And maybe you will make your own desition.
If there was a single project, the task would be easy - I could have just put it under a VCS and be done.
But I have a lot of those projects (some of which are under version control, come are not), which I want all to be in sync. For simplicity's sake, I can say that they are all placed in a single directory, new projects are added sometimes, old ones are deleted, etc.
I'm running Ubuntu on both systems.
What is the best way to keep my work in sync?
You can use https://one.ubuntu.com/ or something else cloudy ;) you can if you want also set up an own cloud with for example OwnCloud(you can mount to local folders http://owncloud.org/support/webdav/)
If you in the future have everything in a vcs you can push to for example github/bitbucket or your own server.
I work on a software project which has a suite of source code that undergoes periodic change. The code is typically promoted to a production environment, and development continues in a development environment. Emergency hotfixes in production need to be backported to development. A third environment for testing may also exist from time to time. Many developers work on this code at the same time, often needing to make changes to the same individual file.
In short, a classic use-case for version control software. Unfortunately, we have a stone age IT department, and we do all our development in a stock Windows XP environment with absolutely no possibility of using any other software without approval - which never happens. We are lucky to have Winzip.
So what's the best way of managing the above workflow without any real tools? At the moment we are just editing files on a Windows shared drive, making ad-hoc working copies into folders with names like "James's Copy of X", doing backups with Winzip, and calling across the room, "is anybody working on this file at the moment?"
Thanks,
James
Edit: Some clarifications:
The irony is that the system is hardly locked down at all - I could download, install and configure TortoiseHg in about 7 minutes. But I need to do this by the book.
I am also actively pursuing getting version control software through official channels, but ETA for that is 6-9 months if ever, so I'm just trying to do the best I can with what I have now.
Finally, trust me, you will be reading about this project on TheDailyWTF one day, so please help me out with what I can do now rather than what management should have done last week.
Get source control. Talk to management, refuse to work, do whatever you can to get it in.
Bring in a netbook, install a SVN server and use that. Run Git off USB drives.
Really - anything.
It is not just an industry standard now - it is irresponsible of you and your management to continue working like this.
After notifying management and explaining that this is an issue, if they do nothing, just let the inevitable happen. Something that shouldn't have been promoted to production will be (regression, bug, new feature, whatever). When they come to blame you, explain how source control can help ensure that such things do not happen again. Perhaps they will listen then.
Ok, two actual options occur to me here.
First. You have Winzip, and you appear to have web access since you're posting on Stack Overflow. Assuming you have the ability to upload files (which isn't a given, since you're still using a generic StackOverflow avatar) you could find - or build - an externally-hosted service that'll allow you to upload a ZIP file via a web browser, unzip it, and then commit the unzipped contents to a Git or Subversion repository. Stick a secure web front end on it (Apache + mod-dav-svn) and you'll have the ability to browse, review and commit changes to individual files. You won't get the benefits of local SVN/GIT capabilities like merging, but you'll have centralized project history. There could even be a quite lucrative business model in this - selling web-based SCM to developers who are stuck on IE6 and WinXP and can't install anything.
Second: You find a junior/admin in your IT team who's just as frustrated as you are at the draconian restrictions being enforced, persuade them that you know what you're doing, and get them to 'accidentally' set up a local administrator account on your workstation. WinXP is sufficiently insecure out of the box that this shouldn't be too hard to make this look like an accident.
Copy and paste the files into a seperate folder and call that folder vers_x, or get the windows backup utility to save them each day, or another backup utility to do the same? though the first post is correct, strike till vers cont is implemented.
Get git. git init on the current source "repository". Install git on everyone's pc's.
Also, the strike idea is definitely not so bad in this case.
I want to set up a source code control system that:
is networked, so users can access it at work or on the road
does not need to provide sharing, lock mode is sufficient
there will be only three users and they will never be working with the same code
we have no system administrator and not much knowledge in that area so the set up and config must be dead simple.
will be installed on a Windows server
open source or free
Suggestions please.
the SIMPLEST system is what we here call the "Hey Chris" system. We have a networked drive that everyone can mount, and if you want to edit something you shoud "Hey, Chris, are you working on blahblah.cpp?" and Chris says "Nope." and then you edit blahblah.cpp, and stick it back on the shared drive... If you want versions, just back up the networked drive every night.
I never said it was the BEST system, just the simplest.
SVN covers all of these, and is quite easy to set up.
Wrt point 2, sharing tends to be better than locking, as a file that is locked by someone who then goes on holiday/dies/etc. needs to be unlocked by someone before it can be worked on by another developer. SVN supports sharing 'out of the box'.
Mercurial or Git
Try Subversion (svn).
Edit: Rich beat me to it =D. And yes, as he points out sharing is better than locking. Sounds like you're a SourceSafe user. Those were the same set of problems I was trying to address when moving out from SourceSafe =)
I'm surprised no one recommended the Fossil version control system. It checks all of the askers requirements. It's stable and simple, consists of just a single self-contained executable, allows easy admin with a UI and only uses HTTP(s). And yeah, runs on Windows.
In addition it provides a nice web interface, and also manages bug tracking, and wikis.
It's made (and used) by the SQLite people, and that's a guarantee of reliability for me.
The simplest version control system I am aware of is a Revision Control System RCS. It is a command line utility that is available out of the box on Linux systems. It's usage is quite simple.
First. Inside current directory, create a directory where RCS's information will be stored:
$ mkdir RCS
Second. Store (check-in) a file into RCS:
$ ci -t-"My notes" notes.txt
Original file gets deleted.
Third. Restore (check-out) original file from RCS:
$ co -u notes.txt
Fourth. Edit file as needed, now it can be restored any time:
$ vim notes.txt
RCS is also working with binary files, and supports many subsequent changes to a file.
I can only add my voice to the "use subversion" chorus. But you were also asking about simple installation and administration.
For that I would point you to VisualSVN Server. It is an easy to use server installation on Windows. And it is free.
Or if you want to go with a manual setup (maybe because you don't want to use the apache bundled with visualsvn server) follow Jeff's Setting up Subversion on Windows.
I really dig Git and GitHub for this. Git is nice because each developer can check things in and go through the history even when they're offline (say, on an airplane or in the backwoods somewhere), then push their changes to a central repository when they are back online. GitHub works really, really well as that central repository, and includes a lot of very handy tools for reviewing and commenting on other people's checkins.
The basic commands that you use day-by-day boil down to:
git add .
git commit -m "this is a note"
git pull origin master
git push
Git handles most conflicts very well, and it's fast, fast, fast, since the entire repository is on each machine.
Kyle Cordes wrote a blog post about getting started on Windows.
I recommend Tortoise SVN. SVN is a source control environment that's easy to set up and use on Windows, and Tortoise is an add on that integrates with windows explorer.
Despite being simple to use, it allows different people to work on the same file and merge their changes. Even though that "can't happen" I predict at some point you'll be happy that it works that way.
Darcs provides all this and a lot more. It's a distributed version contoll system, which would make it easier to access the data on the road. You can send/receive patches (similar to revisions) through email or ssh.
The thing about darcs that I like the most is that it's really verbose. It really tries to help you.
Lots of recommendations for SVN, but I'm not sure I'd call that "simplest" from an admin point of view. You still need to set up a server, IIRC. In comparison, a DVCS like Mercurial makes no distinction between "repository" and "working copy". To put something on a server (which can be any folder you have file-sharing access to), you can just "push" it there.
You also mention working on the road. DVCS are particularly good at this. Your laptop will have the whole history, so you only need to touch the server if you want to push or pull, not just to do a diff or check the history.
Disclaimer: I'm stuck on TFS and I hate it.
My source control structure looks like this:
/dev
/releases
/branches
/experimental-upgrade
I branched from dev to experimental-upgrade and didn't touch it. I then did some more work in dev and merged to experimental-upgrade. Somehow TFS complained that I had changes in both source and target and I had to resolve them. I chose to "Copy item from source branch" for all 5 items.
I check out the experimental-upgrade to a local folder and try to open the main solution file in there. TFS prompts me:
"Projects have recently been added to this solution. Would you like to get them from source control?
If I say yes it does some stuff but ultimately comes back failing to load a handful of the projects. If I say no I get the same result.
Comparing my sln in both branches tells me that they are equal.
Can anyone let me know what I'm doing wrong? This should be a straightforward branch/merge operation...
TIA.
UPDATE:
I noticed that if I click "yes" on the above dialog, the projects are downloaded to the $/ root of source control... (i.e. out of the dev & branches folders)
If I open up the solution in the branch and remove the dead projects and try to re-add them (by right-clicking sln, add existing project, choose project located in the branch folder, it gives me the error...
Cannot load the project c:\sandbox\my_solution\proj1\proj1.csproj, the file has been removed or deleted. The project path I was trying to add is this: c:\sandbox\my_solution\branches\experimental-upgrade\proj1\proj1.csproj
What in the world is pointing these projects outside of their local root? The solution file is identical to the one in the dev branch, and those projects load just fine. I also looked at the vspscc and vssscc files but didn't find anything.
Ideas?
#Ben
You can actually do a full delete in TFS, but it is highly not recommended unless you know what you are doing. You have to do it from the command line with the command tf destroy
tf destroy [/keephistory] itemspec1 [;versionspec]
[itemspec2...itemspecN] [/stopat:versionspec] [/preview]
[/startcleanup] [/noprompt]
Versionspec:
Date/Time Dmm/dd/yyyy
or any .Net Framework-supported format
or any of the date formats of the local machine
Changeset number Cnnnnnn
Label Llabelname
Latest version T
Workspace Wworkspacename;workspaceowner
Just before you do this make sure you try it out with the /preview. Also everybody has their own methodology for branching. Mine is to branch releases, and do all development in the development or root folder. Also it sounded like branching worked fine for you, just the solution file was screwed up, which may be because of a binding issue and the vssss file.
#Nick: No changes have been made to this just yet. I may have to delete it and re-branch (however you really can't fully delete in TFS)
And I have to disagree... branching is absolutely a good practice for experimental changes. Shelving is just temporary storage that will get backed up if I don't want to check in yet. But this needs to be developed while we develop real features.
Without knowing more about your solution setup I can't be sure. But, if you have any project references that could explain it. Because you have the "experimental-upgrade" subfolder under "branches" your relative paths have changed.
This means when VS used to look for your referenced projects in ..\..\project\whatever it now has to look in ..\..\..\project\whatever. Note the extra ..\
To fix this you have to re-add your project references. I haven't found a better way. You can either remove them and re-add them, or go to the properties window and change the path to them, then reload them. Either way, you'll have to redo your references to them from any projects.
Also, check your working folders to make sure that it didn't download any of your projects into the wrong folders. This can happen sometimes...
A couple of things. Are the folder structures the same? Can you delete and readd the project references successfully?
If you create a solution and then manually add all of the projects, does that work. (That may not be feasable - we have solutions with over a hundred projects).
One other thing (and it may be silly) - after you did the branch, did you commit it? I'm wondering if you branched and didn't check it in, and then merged, and then when you tried to check-in then, TFS was mighty confused.
#Kevin:
This means when VS used to look for your referenced projects in ....\project\whatever it now has to look in ......\project\whatever. Note the extra ..\
You may be on to something here, however it doesn't explain why some projects load and others do not. I haven't found a correlation between them yet.
I think I'll try to re-add the projects and see if that works.
#Cory:
I think that's what I'm going to try... I have about 20 projects and 8 or so aren't loading. The folder structures are identical from root... ie: there aren't any references outside of DEV.