Version Control Questions Megathread (SVN / git / whatever else)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›3 »

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Yes. It has to grab each revision from subversion and subversion is really slow.

# ¿ Jun 18, 2010 06:54

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 12:56

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Vanadium posted:

This is destructive since it rewrites history so I guess you may want to duplicate your branch before trying.

The old version will still be in the reflog so it's really not all that destructive.

# ¿ Jun 29, 2010 20:05

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

git add -i is also likely to be helpful. Basically, commit everything you want to keep in the experimental branch (even if it's not done; at worst you can later change this commit), stash everything else, make the new branch, then unstash.

# ¿ Aug 2, 2010 08:09

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Suppose you're working on a local feature branch and the commit history looks like this:

code:

A---B---D---F
     \
      C---E---G

(i.e. you have three local commits and there have been two commits to the thing you branched from since you branched)

Merging gives you A, B, C, D, E, F, G (and a merge commit), rebasing gives you A, B, D, F, C, E, F. Most of the time the latter is far easier to work with; your unpushed local commits are all in one clump rather than mixed in with commits made to the remote branch, which makes it easier to review or rewrite them.

# ¿ Aug 18, 2010 09:29

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Zhentar posted:

One of the projects I'm working with right now is in a repository with 50 other projects. There's nothing wrong with that.

It depends mostly on the branching model used by the VCS. With inter-file branching (i.e. CVS, SVN, p4, etc.), performance is the only potential concern from having a giant pile of projects in one repo (but how would you even notice if SVN was slower than usual?). With git-style branching where branches are a repository-wide concept, having multiple projects in a single repository simply doesn't work.

# ¿ Dec 23, 2010 20:30

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

wellwhoopdedooo posted:

Considering the fact that links don't exist on Windows in the same way they do on unix systems

Unless you're using a version of windows released in the last decade.

# ¿ Apr 21, 2011 23:31

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Why do you need some special feature to only commit some of the modified files?

# ¿ May 2, 2011 17:18

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Perforce isn't noticeably slower than the other centralized VCSs I've used (svn, cvs, vss, tfs), but all of them are painfully slow when you're used to git, even on windows.

# ¿ Aug 16, 2011 04:36

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Tulenian posted:

The thing that makes Perforce slow (for me) is the need to mark a file for edit on the central server when developing. When you're working on a large dev team, that means a 1-2 second delay to start working on a file. Compare that with Git or SVN where you can just start editing immediately and it's very noticeable.

I just turn that off and use Reconcile Offline Work extensively to pretend I'm using a VCS that isn't dumb.

# ¿ Aug 17, 2011 03:26

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

still don't see what's so hard about running an installer and clicking next a few times

# ¿ Aug 17, 2011 19:22

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Does anyone other than Canonical actually use bzr? I don't think I've ever run into a project that uses it which wasn't on launchpad.

# ¿ Aug 19, 2011 05:22

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

when actually writing code I almost exclusively use -am with a <5 word commit message then before pushing review each commit, squash and split like crazy, and add actual commit messages

I've strongly considered trying to figure out a way to just autocommit every time I save a file so that I can completely forget about dicking around with source control while coding

# ¿ Sep 5, 2011 05:50

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Clone the empty svn repo as a git-svn remote, dcommit the git branch you want to push to svn, and wait a few hours.

# ¿ Oct 6, 2011 18:00

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

It's not very hard to add a post-update hook to do so.

# ¿ Oct 25, 2011 02:08

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

uXs posted:

Merging is possible step by step too, you know. Admittedly, it won't look pretty :-)

I suppose you could rebase step by step on a temp branch and use the result of that as the merge conflict resolution.

# ¿ Oct 25, 2011 22:19

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

git push origin :branchname to delete a remote branch.

nexus6 posted:

This is working well (thus far) and makes sense, but I do have one issue. In order to test my changes locally I need to modify certain files and I need these to be present across any branches I create. However, I only want each branch to contain the modifications I've made, not any of these config changes. I don't want any config changes pushed up to the central server.

The approach I've taken for this is to have the following structure: master --> dev --> feature branch, where dev has the configuration changes committed, and then rebase the feature branch onto master before pushing.

Plorkyeran fucked around with this message at 18:45 on Dec 1, 2011

# ¿ Dec 1, 2011 18:42

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

In an ideal world you'd have a pre-receive hook that builds the project and runs your comprehensive test suite on each individual commit.

# ¿ Dec 10, 2011 01:24

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

git reset origin/master --hard

Note that in step five you probably should have reverted rather than resetting. Rewriting private history can be awesome, but rewriting public history rarely is.

# ¿ Feb 28, 2012 19:30

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Yes, or just git revert HEAD for the specific case of reverting the last commit.

# ¿ Feb 28, 2012 20:46

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

I can't really imagine any situation where I'd choose to use TFS short of "Made by Microsoft" being a hard requirement.

# ¿ Feb 28, 2012 21:30

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

I don't think TFS is awful per se, but it's a centralized source control system that's overly tied to Visual Studio and doesn't really have any compelling features to make up for this.

# ¿ Feb 28, 2012 22:31

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Testing the result of merging several branches before pushing to production would be a good first step.

# ¿ Mar 8, 2012 02:19

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

SVN does not have any concept of a tag; it's purely convention. Even with the standard setup, you can freely commit to existing things in the tags directory.

# ¿ Mar 29, 2012 17:04

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Takes about 30 seconds to cherry-pick them over to the right branch if there's no conflicts. Alternatively, make a temp branch and interactively rebase it onto the correct branch, discarding all of the commits from the bad branch, then reset the correct branch to the temp branch.

# ¿ Apr 9, 2012 04:06

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

The article was basically "the installer asked me questions I didn't know the answer to and I refused to just accept the defaults."

# ¿ May 21, 2012 20:50

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

clearcase is terrible and jumping through dumb hoops to avoid having to touch it is usually worth it

# ¿ Jun 1, 2012 05:40

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Definitely don't use a cron job for syncing unless you have no other choice (and if you have no other choice you probably chose poorly when decided on a repo host). Post-receieve/changegroup hooks on the upstream work much better.

# ¿ Sep 25, 2012 15:08

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

filter-branch works fine on the initial commit; it's just rebase -i that doesn't.

# ¿ Oct 10, 2012 17:47

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

I make at least one commit per minute while doing things since having uncommitted things makes me only slightly less twitchy than unsaved things. Most of these commits are eventually removed entirely, and those that aren't are completely rewritten at least once. I have no idea how I'd survive with a VCS without history editing.

Actually, I do know. I'd use git for everything and write git-Dumb VCS bindings if they don't already exist.

# ¿ Apr 4, 2013 09:34

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Strong Sauce posted:

I haven't done this yet but I'm thinking that once A gets merged into dev, I just go back onto the dev branch, create a new temp branch, "C" then merge the old B branch into C.

Why? Once "A" is merged into "dev", just pull "dev" then rebase "B" onto "dev".

# ¿ Apr 18, 2013 03:51

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

You can set up a service hook at bitbucket to automatically POST a url of your choice when commits are pushed to it, and then you just have to run the deployment script whenever that URL is hit.

# ¿ May 19, 2013 04:52

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

As a general rule, git submodules are useful (but pretty awkward) for external deps that you want to have pinned to a specific version, while git subtree is useful for sharing files between multiple repositories entirely under your control. Neither of these really covers what you want.

# ¿ May 21, 2013 17:11

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Marsol0 posted:

That's what I was wondering. So far it looks like maintaining two separate repos will be easier overall to manage and for the team responsible for the stored procedures. Though it does mean that I have to keep an eye on that second repo and make sure my script points at it (not horrible). The concern is if someone after me has to do the same thing, the best I can do is document the process and hope they get it right, or make it so that my deployment script also, at a minimum, clones the stored procedures into a directory outside of itself. Maybe clone the data repo to a temporary directory, change the working set to a specified version and deploy from there. We have another deployment script that does that, but I'm not sold on that idea.

Ultimately, if your solution requires that someone follow some directions and set things up manually, they will hate you forever, while if it is a fully automated janky mess that somehow manages to work on their machine the first time, they will at most roll their eyes when they see how it works.

# ¿ May 21, 2013 20:58

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

git's branching model does not support multiple projects per repository.

Bare repositories are just copies of the repository without a local checkout. One of the core ideas behind git (and DVCSs in general) is that there is no real difference between local repositories and repositories on servers.

# ¿ Jun 7, 2013 21:17

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

evensevenone posted:

Right now I just have a tagged commit that has the needed stuff and when I switch branches I cherry-pick it. Then when I submit my code I just rebase, move that commit to the end, and then reset that branch up a commit. But this seems overly complex and I'm always afraid I'll fat finger something durning a rebase.

You can skip a step and just remove the commit while rebasing.

I've been doing the same sort of thing for a few years now, and while it does result in needing to do the occasional ninja force-push I think on the whole it might actually cut down on bad pushes, since it forces me to be in the habit of always checking exactly what I'll be pushing before pushing and I've found other problems while removing the commits that shouldn't be pushed quite a few times.

I wouldn't object to a less stupid workflow, though. It seems like it should be possible to automate not pushing specifically marked commits.

# ¿ Jun 9, 2013 00:25

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

evensevenone posted:

Honestly if it wasn't so easy to just accidentally delete a line during an interactive rebase and lose a commit forever I'd be happy. git sure gives you a lot of rope to hang yourself with.

Commits aren't deleted immediately when the last references to them is removed, so as long as you notice the commit is missing within a few months you can grab it from the reflog (although finding the right commit can be a bit hard...)

# ¿ Jun 10, 2013 14:27

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

That's not really an issue. Add the upstream as a remote, cherry-pick new commits from the upstream (when I last used it, git-svn barfed on merges and with no shared history the first one would be goofy), and dcommit them to svn. Write a script to automate the cherry-picking if the project isn't mostly dead.

# ¿ Jun 25, 2013 14:31

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

It'd probably be easier to just move the actual definition of the variable defining the key to its own unversioned file.

# ¿ Jun 27, 2013 03:16

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

ToxicFrog posted:

It totally can; the command you're thinking of is git filter-branch. It rewrites history by running a shell command on every commit; make the command something like sed -r -i -e 's/<license key>/XXXXXXXXXXXX/' license.clj and then make sure you don't push the old version of the branch and there you go.

Note that if the repo is nontrivially sized then running this on a ramdisk is very much worth the effort, since it has to checkout and commit -a every commit in the repository.

# ¿ Jun 27, 2013 04:57

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 12:56

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

The plumbing operates on full-tree blobs, but the porcelain mostly exposes commits as if they were diffs. Thinking of commits as deltas is incorrect, but for many purposes is still the right thing to do.

# ¿ Jul 9, 2013 22:34

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›3 »