Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Vinterstum
Jul 30, 2003

CommunityPancakeDay posted:


Currently we have three environments (development, testing and production) and a Vault repository for each environment. When developing on our local machines we check in/out from the dev repo. We then have a separate machine that we use to publish to test & production, so when stuff is ready to go out we have to manually add every single new and modified file to the right Visual Studio project on this machine, check it into the repository and then CruiseControl handles the building and publishing.

Not just weird and goofy, but also incredibly awkward.

The standard approach for this would just to have separate branches for the three environments (in the same repository), and just merge up from one to the next whenever appropriate. Which is a lot easier and less error-prone than doing this manually.

I'd advice your company to evaluate a few different solutions though. Subversion works fine for smaller setups, but really doesn't scale well with many devs and many branches (though it's getting better, apparently).

At work we switched to Perforce a couple of years ago (from Subversion), and have been really pleased with that. It's a commercial solution though. Mercurial also works really nicely if you want a free solution. And it's a distributed solution, which Perforce isn't, meaning you can do all the normal source control operations on just your local repository, then later push those changes to a remote one. On the other hand, Perforce has far better GUI tools. Hence: evaluate :)

Adbot
ADBOT LOVES YOU

Kekekela
Oct 28, 2004
When I want to ignore a file using TortoiseSVN, what I've been doing is:
1 - go to the working copy, right click the file and add to ignore list
2 - Update local copy (if I skip this step I get an error the next time I try to commit)
3 - Commit local copy (need to do this or the parent folder shows up with the pending changes icon)

I think I understand why the second step is necessary: The ignore list is actually maintained by the repository, so I need to update my working copy so that it realizes it doesn't need to track that file anymore. I don't understand why I need the commit in step 3 though.

Or am I completely misunderstanding this, and what is really going on is every working copy has its own ignore list or something?

Any insight as to what's going on here would be useful to me probably even beyond this specific case. I'm loving using this for source control but I've only been at it a couple months, and I think my lifetime of Sourcesafe/Fortress type source control has probably left me with some horrible misconceptions about what goes on under the hood.

Pesch
Nov 4, 2006
Wholly Chao
I'm using SVN for some personal projects and there is something I've been confused on. Are you supposed to create one SVN repository to put all your projects in, or are you supposed to create a seperate SVN repository for each of your projects?

OddObserver
Apr 3, 2009

Kekekela posted:

When I want to ignore a file using TortoiseSVN, what I've been doing is:
1 - go to the working copy, right click the file and add to ignore list
2 - Update local copy (if I skip this step I get an error the next time I try to commit)
3 - Commit local copy (need to do this or the parent folder shows up with the pending changes icon)

I think I understand why the second step is necessary: The ignore list is actually maintained by the repository, so I need to update my working copy so that it realizes it doesn't need to track that file anymore. I don't understand why I need the commit in step 3 though.

Or am I completely misunderstanding this, and what is really going on is every working copy has its own ignore list or something?


SVN stores the ignore list as a property, svn:ignore; and properties are (normally) versionned, too, just like files, so you need to svn commit to get it to the repo.

Kekekela
Oct 28, 2004

OddObserver posted:

SVN stores the ignore list as a property, svn:ignore; and properties are (normally) versionned, too, just like files, so you need to svn commit to get it to the repo.

Cool, thanks. That being the case, why do I have to do the "Update" in step 2?

Filburt Shellbach
Nov 6, 2007

Apni tackat say tujay aaj mitta juu gaa!

Pesch posted:

Are you supposed to create one SVN repository to put all your projects in, or are you supposed to create a seperate SVN repository for each of your projects?

Either works just fine.

If you want to give someone a commit bit to just one project, Subversion supports that. Keeping everything in one repository makes certain operations like testing and debugging multiple projects easier. You can checkout a specific revision of each project, rather than fooling around with correlating revision numbers with timestamps.

I don't recall any specific benefits of a separate svn repository for each project.

Lysidas
Jul 26, 2002

John Diefenbaker is a madman who thinks he's John Diefenbaker.
Pillbug

Kekekela posted:

Cool, thanks. That being the case, why do I have to do the "Update" in step 2?
See the section of the Subversion book about mixed revision working copies, specifically that a directory must be fully up-to-date before you can commit property changes to it.

Kekekela
Oct 28, 2004

Lysidas posted:

See the section of the Subversion book about mixed revision working copies, specifically that a directory must be fully up-to-date before you can commit property changes to it.

Awesome, thanks!

SmirkingJack
Nov 27, 2002

Pesch posted:

I'm using SVN for some personal projects and there is something I've been confused on. Are you supposed to create one SVN repository to put all your projects in, or are you supposed to create a seperate SVN repository for each of your projects?

As a new guy coming into version control (and SVN in particular), one thing that I am learning is that there aren't really any (or many) "supposed to's." It seems more like, "here are the tools, use them in whatever way works best for you." While I appreciate freedom and flexibility, it makes it hard when all you want to do is get up and running right away :P

Horse Cock Johnson
Feb 11, 2005

Speed has everything to do with it. You see, the speed of the bottom informs the top how much pressure he's supposed to apply. Speed's the name of the game.
Back again with another SVN question. What's the correct way to go about creating a branch of a branch? Or is there even such a concept?

For example, let's say I have a repository with 2 branches off the trunk: a development branch and a testing branch. Stuff gets merged from development to test and then from test to the trunk before going into production.

code:
/
    /trunk
    /branches
        /development
        /test
    /tags
Now let's say I want to start development on a new feature so I branch the development branch. Where should I create that branch? In my mind it just seems to make sense to create it underneath the development branch like so:

code:
/
    /trunk
    /branches
        /development
            /newFeature
        /test
    /tags
and then merge the newFeature branch up to the development branch when I'm all done rather than creating a whole new branch alongside the development and test branches, but TortoiseSVN doesn't seem to like that very much. Is my thinking about this all wrong or am I just doing it wrong?

Avenging Dentist
Oct 1, 2005

oh my god is that a circular saw that does not go in my mouth aaaaagh
Answer: don't use SVN if you care about branching a lot.

Triple Tech
Jul 28, 2006

So what, are you quitting to join Homo Explosion?

Avenging Dentist posted:

Answer: don't use SVN if you care about branching a lot.

More correct answer: don't use SVN if you care about merging after branching.

Why you would branch without merging I guess is an exercise left to the reader.

Vinterstum
Jul 30, 2003

CommunityPancakeDay posted:

Is my thinking about this all wrong or am I just doing it wrong?

Parent and child branches makes sense conceptually, but you probably don't want your actual tree structure that way. Just look at the default SVN structure: The branches that are children of trunk aren't under trunk, they're under the "branches" sibling of trunk.

If you really want to make it clear that the testing and production branches are separate from the development branches, you can do something like this:

code:
/
    /development
         /trunk (has code)
         /branches
            /newFeature (has code)
    /testing (has code)
    /production (has code)
But as has been mentioned: If you are in any way going to be dealing with branches and it's a commercial environment with multiple developers... Go with Mercurial or Git (or Perforce if you can pay). There's absolutely no reason to use SVN (in this scenario). There's many things Mercurial/Git do better than SVN, but nothing SVN does better than Mercurial/Git (except for Windows GUI tools when it comes to Git, maybe. And, uh, taking up less disk space).

Vinterstum fucked around with this message at 19:52 on Aug 24, 2009

Pardot
Jul 25, 2001




Triple Tech posted:

Why you would branch without merging I guess is an exercise left to the reader.

Because you squash the branch down to a single commit and rebase it onto master instead of merge :c00lbert:

Steve French
Sep 8, 2003

Triple Tech posted:

More correct answer: don't use SVN if you care about merging after branching.

Why you would branch without merging I guess is an exercise left to the reader.

Branch off version snapshots (1.0, 2.0, etc) instead of just creating a tag for that version for backporting bug fixes.

NotShadowStar
Sep 20, 2000
Is Trac pretty much the best game around when it comes to source browsing & ticket management? I'm using Github for public stuff but for internal projects that have no need to be put out into the public I've been using SVN and thinking about Trac (although it's kind of :psyduck: to get working under FastCGI)

Pardot
Jul 25, 2001




NotShadowStar posted:

Is Trac pretty much the best game around when it comes to source browsing & ticket management? I'm using Github for public stuff but for internal projects that have no need to be put out into the public I've been using SVN and thinking about Trac (although it's kind of :psyduck: to get working under FastCGI)

I use github for both public and private repos, and pivotal tracker for internal tickets. There's a nice little sintara app that can be a post-receive hook from github and update tracker. But the ticket and repo might not be as tightly integrated as you'd like if you like trac.

You could checkout redmine if you want them more integrated. I used that a year or two ago, and it was decent, but I really like pivotal tracker's way of doing tickets.

king_kilr
May 25, 2007

NotShadowStar posted:

Is Trac pretty much the best game around when it comes to source browsing & ticket management? I'm using Github for public stuff but for internal projects that have no need to be put out into the public I've been using SVN and thinking about Trac (although it's kind of :psyduck: to get working under FastCGI)

Trac is my second favorite. With my first being still in development trac replacement :/ I use my thing exclusively for my personal, and not yet public code, but I'm hoping it'll be able to full on replace trac/redmine/everything else full on by the end of the year.

Tulenian
Sep 15, 2007

Getting my 'burg on.
Am I being a pansy for not wanting to use Git on Windows due to my love of TortoiseSVN? It sounds neat but the lack of a good Windows Explorer plugin for Git (or even just decent Windows command line support) is really just killing my desire to use it on a new personal project.

ehnus
Apr 16, 2003

Now you're thinking with portals!
I haven't had any usability issues with msysgit at all on the command line. What kind of problems is it giving you?

king_kilr
May 25, 2007

Tulenian posted:

Am I being a pansy for not wanting to use Git on Windows due to my love of TortoiseSVN? It sounds neat but the lack of a good Windows Explorer plugin for Git (or even just decent Windows command line support) is really just killing my desire to use it on a new personal project.

There is: http://code.google.com/p/tortoisegit/ . I've never used it though, I'm a cmd line *and* Linux whore.

BizarroAzrael
Apr 6, 2006

"That must weigh heavily on your soul. Let me purge it for you."
I've got a pretty big issue here, can anyone talk me through causes of conflicts in SVN after updates?

A guy ran an SVN Update on his project last night after committing a number of changes. The changed files came up as conflicted and are now marked as unversioned in the directory, having apparently reverted to how they were priot to him making changes, so he has to delete them and revert the folder, which results in him getting the files with his committed changes from the previous day. I've had several people run the same update script for a few weeks now, and this is the first time I've come across this.

BizarroAzrael fucked around with this message at 10:56 on Aug 26, 2009

Ferg
May 6, 2007

Lipstick Apathy

king_kilr posted:

There is: http://code.google.com/p/tortoisegit/ . I've never used it though, I'm a cmd line *and* Linux whore.

TortoiseGit, as well as GitExtensions fall flat on their face with regards to functionality in my experience. I just don't see Git as a tool you can use outside of the commandline, or at least without using both simultaneously. I just use the bash shell that msysgit includes and run it purely out of that.

Itaipava
Jun 24, 2007

BizarroAzrael posted:

A guy ran an SVN Update on his project last night after committing a number of changes. The changed files came up as conflicted and are now marked as unversioned in the directory, having apparently reverted to how they were priot to him making changes, so he has to delete them and revert the folder, which results in him getting the files with his committed changes from the previous day. I've had several people run the same update script for a few weeks now, and this is the first time I've come across this.

I'm no guru, but could you elaborate on what this "update script" does more specifically? Usually, SVN won't (shouldn't) let you perform a commit if your working copy is out-of-date (to avoid repository conflicts on stuff that's been committed by other people), but you're telling us that he first committed and then updated, so it sounds like that wasn't the case.

BizarroAzrael
Apr 6, 2006

"That must weigh heavily on your soul. Let me purge it for you."

Itaipava posted:

I'm no guru, but could you elaborate on what this "update script" does more specifically? Usually, SVN won't (shouldn't) let you perform a commit if your working copy is out-of-date (to avoid repository conflicts on stuff that's been committed by other people), but you're telling us that he first committed and then updated, so it sounds like that wasn't the case.

The script runs a backup (copies folder to folder_backup) then SVN cleanup and then SVN update on the whole project. It determines a revision number based on a file published by another department who will check the build the following morning and publish necessary changes to make it work. The script also runs a build and compiles the project.

So this guy updated overnight to what was probably essentially the HEAD revision at that time (unless someone was up really late submitting changes, which I am not aware of anyway) and arrives the next morning with that last night's revision on his machine. He made some changes, committed them and did a few more local changes before leaving once more and running another overnight update. He was the only one changing these files (pretty sure he was getting locks for everything) and when the update ran they were conflicted.

Itaipava
Jun 24, 2007

BizarroAzrael posted:

He made some changes, committed them and did a few more local changes before leaving once more and running another overnight update. He was the only one changing these files (pretty sure he was getting locks for everything) and when the update ran they were conflicted.

Since he had local, non-committted changes, is it possible that the script decided to update to a non-HEAD revision, one that was -before- his commit, for instance? I can't see how SVN would willingly take a file out of version control - does he still have his .mine conflict files?

geeves
Sep 16, 2004

I've used SVN for years and have come to appreciate it. Hell, everyone would if they had to use StarTeam before that. But my question isn't so much about what is being used, but when to branch.

Right now we're debating to either:

A) Trunk is always for continuous development. Branch release candidate while working on new version in Trunk; merge fixes on Branch back into the Trunk. Use a Tag for the actual release (may be overkill to use a Tag, but that's it in theory).

B) Branch current revision, make it release-worthy then merge into Trunk, keeping Trunk clear of any "sandbox" or new development. So even if a huge refactor or new feature needs its own branch, it possibly could end up be a branch of a branch (in theory).

We're a small team ~ 10 people - most are new to SVN and source control in general. My old company we had roughly the same and used option A and rarely had a problem. Yes, the build broke from time-to-time, but I would say it was solid 95% of the time and we never had any major problems. We also had 4 major products off of one code base.

I'm not looking for "use this because it's better", but has anyone hit any pitfalls with option B. I know how option A works and have not had any major issues with it in my 4 years using it that method. There ahve been issues or problems with merging here and there, but no show stoppers.

I prefer A, though if it's selected way of doing this B isn't all too bad, if a bit draconian. I've had a lot of wins in selecting technology for this project, so I'm willing to compromise if other developers (who have had experience with source control) prefer something else. They'll still be running to me for help.

sonic bed head
Dec 18, 2003

this is naturual, baby!
Is there any way to prevent certain directories from being checked out by users in SVN? I can't find a hook that corresponds and I'm not using DAV but rather just svn+ssh.

Doc Block
Apr 15, 2003
Fun Shoe

sonic bed head posted:

Is there any way to prevent certain directories from being checked out by users in SVN? I can't find a hook that corresponds and I'm not using DAV but rather just svn+ssh.

It's in the configuration/authorization stuff for the repository. check /path/to/your/repos/conf (or /repos/config, I can't remember).

Of course, it depends on the authorization scheme you're using.

sonic bed head
Dec 18, 2003

this is naturual, baby!

Doc Block posted:

It's in the configuration/authorization stuff for the repository. check /path/to/your/repos/conf (or /repos/config, I can't remember).

Of course, it depends on the authorization scheme you're using.

Which authorization schemes work? Can I still use svn+ssh? I would like to just keep using shell accounts rather than set something else up.

BizarroAzrael
Apr 6, 2006

"That must weigh heavily on your soul. Let me purge it for you."
I have a guy who has found that when he tries to SVN update the project, he gets told that there are locks on the project and he should run an SVN cleanup.

I had a similar issue that was fixed by releasing the locks through Tortoise, rather than the cleanup SVN suggests, but in this case I just get told to do a cleanup. On attempting a cleanup, I get an error saying that a [file].svn-base file in the hidden .svn folder can not be copied into a [file].tmp.tmp file.

I don't understand where his locks (or mine) came from, but more importantly I need to know how to straighten out his cleanup so he can update into a working build tomorrow.

Rat Supremacy
Jul 15, 2007

The custom title is an image and/or line of text that appears below your name in the forums
What good ways are there to go about using scm when you are putting large existing *web sites* under version control?

IE where several devs are making small changes all the time, so tagging and deploying is just ridiculous and the data transfer is unfeasible.

Currently the best thing I can come up with is having the production directory on the server as an actual working dir (and protecting the .git folder with .htaccess), then pulling to deploy any changes (the changes are done on a test server then pushed to the origin repo). Is there any real disadvantage of this? The site has been around since 2003 and this huge jumble of code, and I think bolting git on will just help prevent people making index2_bak.new.old.jun2004.php~ files all the time, and also means we can be sure we're updating the latest copy. It is never going to be ideal, but what would you do in this situation?

Ferg posted:

TortoiseGit, as well as GitExtensions fall flat on their face with regards to functionality in my experience. I just don't see Git as a tool you can use outside of the commandline, or at least without using both simultaneously. I just use the bash shell that msysgit includes and run it purely out of that.

This is awesome, I really can't see how it could be improved with a shoddy gui.

nobleclem
Apr 13, 2005
HOW MANY RED TITLES DO I HAVE TO HAND OUT BEFORE YOU PEOPLE LEARN TO STOP CLOSING THREADS IN SH/SC?

haywire posted:

What good ways are there to go about using scm when you are putting large existing *web sites* under version control?

blah blah blah....

Well thats how we are doing it. However I would like to find a better way of dealing with this as right now there is no way for me to tell what changes were sent into production seeing as several commits often are one production update. We use svn right now so I am wanting to see if tagging is an option for us but for a short term we have a web tool that we do our production updates so I am just going to log who, what, and when updates are sent into production. We had a couple instances where a designer put some stuff into production that wasn't production ready. And I got to fix it.

We still have a site that is maintained using the .bak system and we had considered about putting it into svn but decided to just migrate everything to a new server slowly and retire the old one. Someday this will be completed.

Doc Block
Apr 15, 2003
Fun Shoe

sonic bed head posted:

Which authorization schemes work? Can I still use svn+ssh? I would like to just keep using shell accounts rather than set something else up.

Honestly, I don't know if svn+ssh will work. My SVN repo is on a private LAN, so I just use svnserve directly.

It can be done using plain-old svnserve (and possibly also svn+ssh) with authz-db. Open up /path/to/your/repo/conf/svnserve.conf. Either it will have a commented-out line like
code:
# authz-db = authz
which you can just uncomment, or add one. The right side should be an authz-db file ("svnadmin create" should add an example for you in the conf directory). Edit it to your liking, it will let you restrict access by directory.

This is all just off the top of my head, so double-check with the on-line Subversion book.

very
Jan 25, 2005

I err on the side of handsome.
e: i typed some stuff then i realized that it was useless

very fucked around with this message at 13:26 on Sep 5, 2009

wwb
Aug 17, 2004

haywire posted:

What good ways are there to go about using scm when you are putting large existing *web sites* under version control?

--horrors--

We've got a few large, shoddy websites not too dissimlar to this. Ok, well, I put an iron fist down and ended the live updates on production angle. Our pattern is generally now having a production branch and then having people update that, let the responsible parties who can actually touch the production boxes know, and then those folks do an update.

Anyhow, I think once you get the initial commit in, tagging the production release shouldn't hurt that much even if there are 15 million files involved. Really, the bigger trick is to get the hackers hacking on said site to get used to using version control successfully.

Rat Supremacy
Jul 15, 2007

The custom title is an image and/or line of text that appears below your name in the forums

wwb posted:

We've got a few large, shoddy websites not too dissimlar to this. Ok, well, I put an iron fist down and ended the live updates on production angle. Our pattern is generally now having a production branch and then having people update that, let the responsible parties who can actually touch the production boxes know, and then those folks do an update.

Anyhow, I think once you get the initial commit in, tagging the production release shouldn't hurt that much even if there are 15 million files involved. Really, the bigger trick is to get the hackers hacking on said site to get used to using version control successfully.

Well we'll be getting the devs to use version control. This is honesty the best way I can think of doing this, and I've written a script that can update from the repo at the touch of a button.

BizarroAzrael
Apr 6, 2006

"That must weigh heavily on your soul. Let me purge it for you."
Okay, new problem. I would like to version my SVN update scripts, and so have a folder of batch files in the repository so that a)everyone has access to them and b)we can make sure they don't get changed and screwed up for everyone (right now they are on a shared drive)

This presents the problem of the update scripts being changed by the SVN Update that they have called, which can screw things up. I could change the Update command to exclude the scripts directory, but I would like to keep them up-to-date for everyone in case I need to make a change, and I don't want to have to revise a script if they ever change or add anything to the root directory.

The master script, which calls all the other scripts to perform the update, is to be versioned as Update.bat.template, so users will need to cut off the ".template" and unversion it for it to work. Doing this for the other scripts seems impractical though, I don't want users having to muck around with them themselves. I thought about having them versioned as .templates as well, and having the master script rename them. Would it work to have the script rename them all by removing the .template? Then the update would restore the original .bat.template files which would be used next time the update runs.

I think I've just hit on the solution whilst writing this, but I'd like to hear what anyone thinks.

Edit: Weird question: Can I version an empty directory? I'd like all users to have a place to put all the log outputs of the update script without the script throwing up an error every time after the first because the folder is already there.

BizarroAzrael fucked around with this message at 16:55 on Sep 9, 2009

nobleclem
Apr 13, 2005
HOW MANY RED TITLES DO I HAVE TO HAND OUT BEFORE YOU PEOPLE LEARN TO STOP CLOSING THREADS IN SH/SC?

BizarroAzrael posted:

Edit: Weird question: Can I version an empty directory? I'd like all users to have a place to put all the log outputs of the update script without the script throwing up an error every time after the first because the folder is already there.

Yes you can version just the directory. What you will need to do is tell svn not to version the contents of the directory. Just add the svn:ignore property on your empty log directory. That should do what you want.

We currently do this for a cache directory. I didn't want someone elses cache data messing up my testing or me dumping all my cache data to mess up their testing.

Adbot
ADBOT LOVES YOU

Belgarath
Feb 21, 2003
I have to use Sourcesafe at work (I know, but it's out of my hands), but I've started using Git for my personal stuff. I was wondering if I could use Git at work, so that I could init a Git repo in my sourcesafe checkout, do some work, make some branches in Git, and then check back into sourcesafe after merging my Git branches into master?

i.e. the checkout from sourcesafe would be the Git master, and I do all my work in branches, merging back to master when I'm happy, and then checking back into sourcesafe.

It doesn't sound all that unreasonable to me, assuming I setup my .gitignore file to ignore the relevant Sourcesafe files.

We're moving from Sourcesafe to Clearcase soon too :( If only I could convince them to buy into Git and get Github:FI

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply