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.
Related
I am very confused about how this all works, so I am gonna make a series of questions.
So I am almost at the end of my final degree project and I have been using Github for version control. At some point, I had to store large files (>100mb) and got this message:
My first question is: what does actually happen if I click "commit anyway"? does it mean that I can't commit anymore?
Anyway, I have done research about lfs and eventually installed it in my repo (btw, this is a Unity project). I have followed this video: https://www.youtube.com/watch?v=09McJ2NL7YM&t=615s. This guy suggests using this custom .gitattribute: https://gist.github.com/nemotoo/b8a1c3a0f1225bb9231979f389fd4f3. This automatically tracks all files with a certain extension and pushes them in lfs. At the time I thought this was cool, until I realised that this file made me push all tracked files no matter how big or small they are. what I should have done is use bash for pushing to lfs only when I would get the message above (so only for files >100mb). Since my whole degree depends on this project, I did not want to mess with GitHub and spend time trying to "fix it", but I want to know if there is any way to restore the whole history and made it as I have never used lfs (?)
Lastly, since I got loads of files stored in lfs, I get that whenever someone re-clones my repo, can just do git lfs fetch --all and then git lfs pull (and this should use up my bandwidth, right?). But.. what happens if someone decides to just "download" the project ("download zip)? Well, I have tried it, and all those files are missing completely.. Is there a way to download the project with the original files instead of pointers?
Also, if you exceed the free 1gb data pack that GitHub provides, and stop paying for additional storage, do you lose all those files??
At some point in the future, I would like to remove lfs, and if I have to, only store files >100mb (I think they are just 2 in total). But would that still mean that to have a complete version of the project the only option would be to clone the repo instead of downloading (?).
Sorry for the long question but I really need to understand these things.
I am about to start participating in the development of a medium-sized project (~50k lines) that was until now written by a single person, and not versioned; as a result folders are cluttered with different versions of the same file (named file1, file2, file3, etc.).
I proposed to start using a VCS for it (a priori Mercurial, which is the only one I've ever used -- for my personal projects --, but I'm open to suggestions), so I'm taking any good ideas as to how to "start" the repository. E.g., should I make an initial commit with all the existing files, and immediately make a new commit with the unused files removed? Or something else?
(constructive remarks on mercurial vs bazaar vs git vs whatever are also welcome.)
Thanks for your tips.
E.g., should I make an initial commit with all the existing files, and immediately make a new commit with the unused files removed?
If the size of the repository is not a concern, then yes, that is a good starting point. Otherwise you can just commit what's actually used, and go from there.
As for which system, all DVCSes stick to the same core principles. Which one you pick is entirely subjective — the only way to truly know which one you like is to try each one.
I would say use what you are the most comfortable with and meets your needs. As far as where to start, I personally would seed the repo with the current source as is, that way you can verify that everything builds and runs as expected. you can make this initial seed a branch. That way you can always go back to your starting point before refactoring.
My approach to this was:
create a Mercurial repository in the existing project folder ("existing")
commit all project files to "existing"
create an empty repository in what a different location ("new")
As files are tested and QA'd (this was necessary because there was so much dross in "existing") pull them from "everything" to "new".
Once files had been pulled into "new"; delete the corresponding files from "existing". If access is needed to these files while the migration is under way, push them back from "new" to "existing".
This gave me the advantage of putting everything under some sort of control for recovery purposes, control over introducing the project to the DVCS. Eventually the existing project folder became completely tested and approved for the project moving forward. At this point the "everything" directory could be deleted or changed into a working folder; and "new" became the actual project folder.
I think Mercurial is a good choice. Lightweight, fast, very simple to use and well-integrated with Windows (if that's the platform you're dealing with).
I would probably get rid of all the clutter before the first commit. Delete everything you don't care about, run all the necessary tests and only then do the commit.
Yes, I'm dead set against the 0-day cluttering of repos.
Granted, a 50K SLOC project isn't very big, but if you commit files you already know you won't need, they will make your repo slightly bigger.
Also, remember to check that the tree doesn't contain large binary files. If it does, get rid of them if at all possible.
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.
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.