|
I don't see how this has anything at all to do with what git-annex is designed for.
|
#
?
Jan 19, 2014 16:11
|
|
|
|
| # ? Jun 1, 2024 06:31 |
|
|
To weigh in on the Git + Dropbox combination. On a first look it might seem like a good idea and then you'll ask for opinions on a forum and people will tell you it is a stupid thing to do with well-founded arguments so you don't do it and continue looking for alternatives. And they're right. You shouldn't use it for your company's code base, BUT I've been using this combo for years for personal projects and holy poo poo is it convenient (and it hasn't failed my yet). At first I initialized a bare repo on Dropbox and pushed and pulled from that, but that is actually a bad idea. However, having a repo somewhere else (f.e. GitHub) and cloning that into a Dropbox folder and working from there is so very convenient. (I do this while developing for Linux, OS X and Windows.)
|
|
#
?
Jan 20, 2014 15:38
|
|
|
as long as you don't use the sharing features of your preferred cloud sync software anywhere within your development directories, it's perfectly fine for personal development needs.
|
|
#
?
Jan 21, 2014 20:00
|
|
wolffenstein posted:as long as you don't use the sharing features of your preferred cloud sync software anywhere within your development directories, it's perfectly fine for personal development needs. Why not? You can share an entire directory and any browser-side technologies (js, html, css) will work just fine.
|
|
|
#
?
Jan 21, 2014 20:38
|
|
|
Your VCS and you will go nuts once modifications are made in a shared folder. Imagine trying to work on separate branches. If you aren't using VCS, then it works fine until two or more people edit a file at the same time. You might be confusing my terminology, but most cloud sync services allow you to mark a folder as shared and others can edit it. Sharing a read-only link is perfectly fine; you're the only one that can edit the file. wolffenstein fucked around with this message at 22:22 on Jan 21, 2014 |
|
#
?
Jan 21, 2014 22:19
|
|
|
aerique posted:To weigh in on the Git + Dropbox combination. On a first look it might seem like a good idea and then you'll ask for opinions on a forum and people will tell you it is a stupid thing to do with well-founded arguments so you don't do it and continue looking for alternatives. Point taken but I fail to see how git + dropbox is more convenient than, say, bitbucket using git.
|
|
#
?
Jan 21, 2014 23:43
|
|
|
wwb posted:Point taken but I fail to see how git + dropbox is more convenient than, say, bitbucket using git. I don't know, I've never used bitbucket. I was just putting down an opinion against people saying Git + Dropbox should never be done.
|
|
#
?
Jan 22, 2014 00:23
|
|
|
Just spin up a $5/mo. Digital Ocean droplet to make somewhere to sync to if you don't want source hosted by Github, bitbucket etc.
|
|
#
?
Jan 22, 2014 04:17
|
|
|
wwb posted:Point taken but I fail to see how git + dropbox is more convenient than, say, bitbucket using git. If you use multiple machines, git can get a little bit iffy. I.e. say you are machine A and you push some changes. Then later on machine B you were working on that branch and forgot to fetch. You commit some changes and then decide to rebase. Then you push, but because you had rebased, you had to do a git push --force (because it wasn't a fastforward). Now whatever you had on machine A was lost (or will be lost once you pull), and git wouldn't have warned you because you had done --force. This really bites you if you set up your remotes as mirror=push and you don't even have to do --force to do non-FF pushes. having a single working directory/repo that is synced though other means (i.e. dropbox or whatever) prevents that problem, because git is only dealing with a single working directory/index. I don't think it's a good idea per se, but there is a gap there that is filled by syncing rather than using git 100%.
|
|
#
?
Jan 22, 2014 09:28
|
|
|
Yeah, it is nice that one doesn't have to push changes if you're in the middle of something and have to reach it from different locations (but not at once), say when going from home to work. Like I said: convenient, nothing more.
|
|
#
?
Jan 22, 2014 13:32
|
|
|
evensevenone posted:If you use multiple machines, git can get a little bit iffy. I.e. say you are machine A and you push some changes. Then later on machine B you were working on that branch and forgot to fetch. You commit some changes and then decide to rebase. Then you push, but because you had rebased, you had to do a git push --force (because it wasn't a fastforward). Now whatever you had on machine A was lost (or will be lost once you pull), and git wouldn't have warned you because you had done --force. I'm probably just old school, and used to working on 3+ computers, but I never have had this problem outside of being too drunk to remember to push things.
|
|
#
?
Jan 22, 2014 16:16
|
|
|
evensevenone posted:If you use multiple machines, git can get a little bit iffy. I.e. say you are machine A and you push some changes. Then later on machine B you were working on that branch and forgot to fetch. You commit some changes and then decide to rebase. Then you push, but because you had rebased, you had to do a git push --force (because it wasn't a fastforward). Now whatever you had on machine A was lost (or will be lost once you pull), and git wouldn't have warned you because you had done --force. If you're force pushing by default you get exactly what you deserve. I'm not even sure how you're rebasing such that you would end up in this situation without knowing what was happening. Never stop using git log --all --graph --decorate all day every day.
|
|
#
?
Jan 22, 2014 18:07
|
|
|
It's not that it isn't totally preventable with a little bit of care, it's just annoying that it requires thinking about at all. I use a rebase workflow instead of a merge workflow so force pushes are needed. You'd think git could tell which pushes are pure rebases or rebases+fastforwards and allow those, and just require --force when commits are actually being lost or changed, but I just don't think its designed that way. Anyway the gist of it is that if you work on multiple machines, you can't use --mirror=push for your remotes safely, and if you use certain workflows, you have to use --force and --force isn't safe either.
|
|
#
?
Jan 22, 2014 18:34
|
|
|
A recent release of git added the --force-with-lease push option, this is like --force, but if your remote tracking branch is different to that on the remote server (i.e. you haven't fetched your refs before pushing) then it will fail. It's presumably not the default yet since it's still experimental. Strictly they're only saying that --force-with-lease=$branch:$commit_id is stable behaviour, but --force-with-lease=$branch defaults to --force-with-lease=$branch:refs/remotes/$remote/$branch, and --force-with-lease without a branch defaults to all branches. Also, don't ask me about the name, I have no idea why it's called that, it was called --lockref earlier in its development, and I was more interested in its functionality when I was writing scripts to sync multiple repositories and rollback if there's an unexpected change, than a safer --force option.
|
|
#
?
Jan 22, 2014 19:32
|
|
only
|
I migrated the work repo and workflow to git/gerrit/cgit today, with tons of documentation and references. Feels good man.
|
|
#
?
Jan 23, 2014 08:29
|
|
|
evensevenone posted:If you use multiple machines, git can get a little bit iffy. I.e. say you are machine A and you push some changes. Then later on machine B you were working on that branch and forgot to fetch. You commit some changes and then decide to rebase. Then you push, but because you had rebased, you had to do a git push --force (because it wasn't a fastforward). Now whatever you had on machine A was lost (or will be lost once you pull), and git wouldn't have warned you because you had done --force. This isn't git's fault, imo - it will tell you that your remote branch has diverged and not allow the push. That's warning enough that something ain't right, surely?
|
|
#
?
Jan 23, 2014 11:51
|
|
|
I have to agree that falls clearly under the "then don't do that" heading. You should have pulled, but you forgot, so the warning is there to remind you to pull.
|
|
#
?
Jan 23, 2014 17:22
|
|
|
Hey, I want to get my feet wet in version control, but unfortunately the OP hasn't been edited since 2009. (Which I can't really criticize, because I haven't updated the post from my SQL thread in about that long.) Can you recommend some basic software that would be good for a first timer, maybe a website or a book on the subject that I could read? Don't get me wrong, the concept of version control makes a great deal of sense to me, but when you start throwing around terms like "push" or "lease" or "branch," I start to get a little daunted and start thinking things like "well what if I just kept a copy of the website in a folder on my desktop and work from that?" Anyway, where do I begin?
|
|
#
?
Jan 23, 2014 18:16
|
|
|
http://git-scm.com/book If you're using Mac or Windows I'd recommend also getting Atlassian SourceTree for a graphical interface.
|
|
#
?
Jan 23, 2014 18:19
|
|
|
uh zip zoom posted:Don't get me wrong, the concept of version control makes a great deal of sense to me, but when you start throwing around terms like "push" or "lease" or "branch," I start to get a little daunted and start thinking things like "well what if I just kept a copy of the website in a folder on my desktop and work from that?" 1. Why copy a folder to your desktop every single time you make a change? What if you want to look at an older copy? Can you remember if you added something yesterday? Which folder? It becomes unmanageable very quickly. Recording your changes (committing) is just one command and it handles all this and more for you. 2. With a system like git, you can type "git checkout -b <mybranchname>" and start hacking away on your code to try something new. Then, if your experiment is a failure you can type "git checkout master" to go back to where you were. In vulgar terms it's a savepoint system for programmers. There are hundreds of reasons to use version control, but those are two of the top benefits that I personally feel make it worthwhile. But there's countless more.
|
|
#
?
Jan 23, 2014 18:32
|
|
|
oiseaux morts 1994 posted:This isn't git's fault, imo - it will tell you that your remote branch has diverged and not allow the push. That's warning enough that something ain't right, surely? That being said, --force-with-lease would fix that problem. As would making sure that the repo on at least one machine has it's own local branches (i.e. treating development on multiple machines the same you would if it were multiple people) And even if git makes it easy to screw that up, I'm still not convinced that using dropbox instead of github (or whatever) makes much sense. If you make changes on machine A, sync them to dropbox, and then can't get to dropbox from machine B for whatever reason, it seems like it would be a pain in the rear end to merge any changes you do on machine B once you can get to dropbox, whereas doing that with an external repo is what a DVCS is for.
|
|
#
?
Jan 23, 2014 18:53
|
|
|
Jethro posted:And even if git makes it easy to screw that up, I'm still not convinced that using dropbox instead of github (or whatever) makes much sense. If you make changes on machine A, sync them to dropbox, and then can't get to dropbox from machine B for whatever reason, it seems like it would be a pain in the rear end to merge any changes you do on machine B once you can get to dropbox, whereas doing that with an external repo is what a DVCS is for. Wasn't he talking about putting a repo in dropbox? A simple "private server" that only really works for one person.
|
|
#
?
Jan 23, 2014 23:24
|
|
|
I've used Mercurial since 2009 for my VC due to the better tools in Windows (at the time), but I have to say, after being forced to use Git at a new job, I like it better. Git Extensions on Windows is just as good/better than the Hg workbench and I prefer the pull --rebase workflow after getting used to it. Even with a couple guys, all the branches in a standard Hg workflow can be tough to follow sometimes. Point being, don't fear the Git world if you're a Windows (.Net/otherwise) dev. Git Extensions will make you fall in love, and stuff like rebase and stash are great. edit: Another tip: change your merge tool to Perforce merge tool and the diff tool to WinMerge for full greatness. B-Nasty fucked around with this message at 03:26 on Jan 24, 2014 |
|
#
?
Jan 24, 2014 03:23
|
|
|
I thought I'd just ask my question here since there's no build systems question thread. What are the common alternatives to Maven? What's the current flavor-of-the-month with regards to build systems? I've spend a day and a half trying to work my way through the Maven documentation but it is, to put it politely, inadequate. I'm approaching it as someone with no experience with build systems. Is there a build system that's more approachable? Or is there an alternative tutorial or guide for Maven rather than the one provided by Apache? edit: I'm going to work through these Maven tutorials: http://books.sonatype.com/mvnex-book/reference/public-book.html , http://books.sonatype.com/mvnref-book/reference/public-book.html and hopefully they'll provide some more insight. Woodsy Owl fucked around with this message at 16:22 on Jan 26, 2014 |
|
#
?
Jan 26, 2014 11:13
|
|
|
What language is your work in? Maven, Ant, and Gradle are the three that Java peeps use.
|
|
#
?
Jan 26, 2014 17:31
|
|
|
I'm trying to setup Tortoise SVN with amazon s3 and I have run into some trouble. I've installed TntDrive to have my bucket listed as a network drive, however I can't set a working repository on there. As soon as you do a commit, tortoise gives errors that the destination has been modified and it can't commit the change. Is there a work around to this? Or will I need to set an ec2 instance to install tortoise on? How does ec2 instances work price wise, it's listed as per hour however I only need the instance running when we need to get latest or do a commit. Can it be configured to turn on via a SVN command? Or is there a simpler method to have tortoise SVN hosted on a webhost and use amazon S3 for storage space? Thank you in advance!
|
|
#
?
Jan 26, 2014 23:38
|
|
|
I've been googling but I can't figure this out... is there a difference between the Ubuntu repository "mercurial-git" and the PyPi package "hg-git"? The former requires the extension to be added as "hgext.git =" and the latter as "hggit =" so I think they might be different, but I can't figure out which I should use.
|
|
#
?
Jan 27, 2014 18:23
|
|
|
You should use the canonical one from https://bitbucket.org/durin42/hg-git
|
|
#
?
Jan 27, 2014 18:32
|
|
|
paberu posted:I'm trying to setup Tortoise SVN with amazon s3 and I have run into some trouble. I've installed TntDrive to have my bucket listed as a network drive, however I can't set a working repository on there. As soon as you do a commit, tortoise gives errors that the destination has been modified and it can't commit the change. Gazpacho fucked around with this message at 00:38 on Jan 28, 2014 |
|
#
?
Jan 27, 2014 23:51
|
|
|
Thanks, I think I will go with having subversion on ec2. What is the difference between using Linux commands to install svn and something like bitnami? I have never setup SVN before. We will be using Tortoise to do our commits. Or I can sign up with unfuddle - they offer unlimited? space for a reasonable price. Has anyone had experience using them? paberu fucked around with this message at 14:33 on Jan 29, 2014 |
|
#
?
Jan 29, 2014 14:01
|
|
|
The easiest way I know if to do a SVN server is to run windows and install http://www.visualsvn.com/server/ FWIW
|
|
#
?
Jan 29, 2014 16:37
|
|
|
Is there a reason you selected Subversion? I would probably pick git or Mercurial running on Bitbucket if you are starting fresh today. It's free for up to 5 people and really easy to get started.
|
|
#
?
Jan 29, 2014 16:57
|
|
|
^^^ that man speaks the truth.
|
|
#
?
Jan 29, 2014 19:31
|
|
|
paberu posted:Thanks, I think I will go with having subversion on ec2. I haven't touched Bitnami. They apparently allow you to start and stop an app on a fixed schedule, and you can manage costs that way.
|
|
#
?
Jan 29, 2014 20:31
|
|
|
Visual Studio Online (formerly Team Foundation Service) isn't a bad choice, even if you just want to use it as a Git repo and ignore all of the other stuff it can do. Plus it's free.
|
|
#
?
Jan 29, 2014 21:12
|
|
|
gariig posted:Is there a reason you selected Subversion? I would probably pick git or Mercurial running on Bitbucket if you are starting fresh today. It's free for up to 5 people and really easy to get started. Sadly Mercurial doesn't like working with large files (anything over 10mb), so my choice is either Perforce or SVN for the assets.
|
|
#
?
Jan 29, 2014 22:40
|
|
|
paberu posted:Sadly Mercurial doesn't like working with large files (anything over 10mb), so my choice is either Perforce or SVN for the assets.
|
|
#
?
Jan 30, 2014 12:13
|
|
|
paberu posted:Sadly Mercurial doesn't like working with large files (anything over 10mb), so my choice is either Perforce or SVN for the assets. I've got a few dozen repos with loads of 10-50mb files in bitbucket here with no issues. We stop at about 50 because things tend to time out over HTTP but we could get much larger if we went over ssh. With SVN we did store loads of 100mb+ files in said visual SVN setup. That was OK for those of us onsite on a 100-1000mb connection to the server but for the remote guy, especially the guy living on the farm on a 1.5mb connection, it was pure hell. SVN tends to get corrupted and the "fix" is typically to blow away your repo and check the entire thing out again.
|
|
#
?
Jan 30, 2014 15:04
|
|
|
wwb posted:With SVN we did store loads of 100mb+ files in said visual SVN setup. That was OK for those of us onsite on a 100-1000mb connection to the server but for the remote guy, especially the guy living on the farm on a 1.5mb connection, it was pure hell. SVN tends to get corrupted and the "fix" is typically to blow away your repo and check the entire thing out again. This might be an issue for us as we are both remote, however bitbucket doesn't recommend having a repository over 1GB. It doesn't seem like there is a neat solution for this anywhere. I do like the way bitbucket is setup otherwise. I was thinking of splitting the project into Mercurial and SVN anyway, it should work fine for a tiny team. Most likely I will just go with unfuddle for the sake of minimizing time burned doing IT tasks. paberu fucked around with this message at 15:18 on Jan 30, 2014 |
|
#
?
Jan 30, 2014 15:11
|
|
|
|
| # ? Jun 1, 2024 06:31 |
|
|
There's also http://git-annex.branchable.com/ , depending on whether git would be a good fit for the rest of the files.
|
|
#
?
Jan 30, 2014 15:27
|
|