sonic bed head posted:

I am pretty sure that your understanding of what svn:ignore does is incorrect. svn:ignore has nothing to do with the repository/server. It is just a setting that tells the client to ignore that directory when updating/committing.

Kekekela posted:

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

BizarroAzrael posted:

If there a good way to find conflicting files in a working copy without attempting an update on it? We have guys that often get conflicts and it would be nice if I could scripts something that finds the problems so they can be fixed by hands, rather than have them kill the overnight update and the subsequent build process.

supster posted:

I'm trying to get some sort of version control working with my remote web server. I set up an SVN repository (on a hosted service) and figured that if I map my remote web server as a drive in Windows (via FTP) then I would be able to use the TortoiseSVN context menus normally in the mapped folder. However they don't appear at all - what are my other options?

I'm basically trying to commit remote files that I have access to via FTP.

supster posted:

Unfortunately FTP is pretty much the only way I can access the files.

supster posted:

Can you explain in some more detail how a distributed system will help me where SVN can't? Maybe you can expand on "synchronize it afterwards".

Maybe I should make clear that I'm not doing anything locally, files live remotely and work is done remotely. So "whatever the gently caress you want locally" doesn't help much because ideally* I don't want to do anything locally.

*using the term "ideally" pretty loosely here

LightI3ulb posted:

I have an SVN that stores reports that can be of quite excessive size through use of a perl module. I've been tasked with trying to find a way to have the module be able to add a file to the svn if the file does not already exist.

The easy part is figuring out whether or not the file exists, I just do a checkout on the file and parse the results. The hard part is trying to add the file to the svn when it does not exist. I need to find a way to be able to retrieve the .svn/entries file for the directory without checking out the entire directory.

Is there any way to get the .svn/entries file on its own, or is there a way to add a file to the svn without the .svn/entries file?

nelson posted:

So if your source files are ASCII text files and you or the people you work with are like me you may want to go with CVS.

nelson posted:

I've managed to screw something up every VCS I've come in contact with .

nelson posted:

CVS is generally better than RCS for group work

nelson posted:

I've managed to screw something up every VCS I've come in contact with .

Lamont Cranston posted:

This is probably really stupid, but I want to know if it's possible. I have a project that I'd been working on and storing in a git repository. About a month ago I decided to scrap everything and start over, and stored that project in a separate repository. Now, there's obviously no reason to keep both of them around, but I'd like to have the old project's history. Is there a way that I can sort of stitch them together, so that after the last commit on the original project, the new project begins? (And it would appear that all of the old files were deleted because the first commit of the new project was empty)

quote:

(during interview/tour/whatever)
So what do you use for version control?
Visual SourceSafe, dictated by management.
...
No, I won't use that.
All of our developers are required to.
Well, this isn't going to work out. Thanks for your time.

beuges posted:

My current idea is to create a repository for each client, and give my dev partner access to the ones he is involved with, rather than having to deal with permissions on a single repository, and likely exposing all my clients even if the actual contents of their projects is restricted.

My tree looks like so:

code:

  root
    |- personal 
    |- client1
    |  |-project1
    |  |-project2
    |-client2
    |  |-project1
  .....

beuges posted:

the impression I've gotten from this thread is that the git clients for windows pretty much suck.

Dromio posted:

code:

git remote add origin ssh://myhomemachine/myapp.git

Zhentar posted:

Not only is the msysgit GUI eye-rape, but when I was trying it out last week trying to checkout a branch would crash it. TortoiseGit is at least usable, although it's still pretty easy to mess up.

Sizzlechest posted:

He's looking to set up a repository at work. He didn't explicitly say it, but I'm going to go out on a limb and guess the following are true:

1. There's a limited and well defined group of people who need access to the system.
2. He's not opening up the source code to the world.
3. His company owns all aspects of the code.
4. It's a networked environment.

There's no real reason to implement a distributed system. Nobody is going to branch the codebase and develop their own flavor for themselves. Nobody has the right to say, "I want to work in private," since that person's work belongs to the company. A distributed setup increases the odds of larger merge conflicts. If you're working on the Linux kernel and don't have an issue with deadlines, then great. In the real world, not so much.

Creating a SVN repository is a single command if you script it, and any SVN admin worth his salt will do so.

You could argue git is easier/better to use, but considering it's a Windows environment, the choice of Subversion is easy.

Milde posted:

Just out of curiosity, what makes Git easier to use than Mercurial for you? I use both, but I find Mercurial a lot simpler UI-wise.

Sizzlechest posted:

No, I said you're cockamamie hybrid setup is.

Sizzlechest posted:

So...you're implementing a centralized system?

You do if you have to look in multiple places for changes committed locally. That's especially fun when someone's out or on travel. With a centralized system, there's ONE place to look for all work in progress.

Sizzlechest posted:

Working copy changes in subversion also run instantly. Commits to a centralized server whether in svn or git will take longer, obviously.

Sizzlechest posted:

And you don't need a decentralized VCS to accomplish this. The type of branching you're talking about is fast and easy in SVN, too. That's not the kind of branching and merging Linus was talking about when he advocates a decentralized system for Linux. You've got thousands of developers working independently, working on things that may never get into an actual release. They need a way to work on their own and merge later. Two developers working in the same shop don't need to work this way, nor is it advantageous for them to do so.

When git first came out, SVN was at 1.4 and it's merging was complete poo poo. In the latest version (1.6), it keeps track of branches and merges just fine. What's more annoying? Resolving a little merge conflict now or a fuckton later?

Sizzlechest posted:

It's a specious argument since a centralized server doesn't require the same kind of merge tracking as a distributed one. There's a single repository everyone is working from. People aren't creating personal branches to work in and then merging them with public ones. They're working from a shared branch or trunk. Merge conflicts get resolved on incremental commits. Merging between branches and the trunk is tracked sufficiently. I suppose you could do private branching in Subversion, but there's no logical reason you'd want to, nor was it designed with that in mind.

Sizzlechest posted:

There's no reason why a private company like the one mentioned needs to implement a distributed system. They don't need have one of them play "merge manager" and reject on a problem like Linus does. They can handle conflicts as they happen, which improves communication.

Thermopyle posted:

I'm fairly noobish when it comes to this stuff...but I think the argument you need to make is why shouldn't they use a DVCS.

Bonus posted:

This is a constant back and forth discussion here on SA. People will claim how you should use SVN because it's "good enough" and "you don't need more". Even after being faced with arguments that distributed version control systems can do pretty much everything that centralized ones can do and that they can do it better.

Knackered posted:

Knackered posted:

I was thinking of using a simple SVN over GIT/Mercurial.
...
Of course the other guy if all for using GIT/Mercurial, which I think is over kill.

Zhentar posted:

AutoCrLf handling is, at best, poor. It will mark files as modified immediately after checking them out, which will interfere with a lot of operations (no switching for you).

HFX posted:

I've been using git with an svn connector. I had been doing all rebase and commits from the master after merging local branches. However, the rebase operation has an unfortunate side effect of removing the local git history for the branch being merged back to trunk. Can someone recommend me a way to keep the history and still be able to do updates from SVN?

Lexical Unit posted:

I'm running git from Mac OS X and developing on a Windows VM.

Thermopyle posted:

I've got a project hosted on github, that I'm totally rewriting. Starting from scratch.

What's the recommended course of action? I'd like to keep the currently functioning version as the latest version available on the project page for now and then when I've got the rewrite functioning make it the latest available version.

This is probably a common occurrence, but I'm new to version control and git.

Spengler posted:

It may be as much a philosophical question as a practical one, but pushing to an extra repo to avoid branching in a situation where it seems warranted seems more like it's extra work than a shortcut.

Scott Chacon posted:

For example, say you want to split your history into one short history for new developers and one much longer and larger history for people interested in data mining. You can graft one history onto the other by replaceing the earliest commit in the new line with the latest commit on the older one. This is nice because it means that you don’t actually have to rewrite every commit in the new history, as you would normally have to do to join them together (because the parentage effects the SHAs).

Let’s try this out. Let’s take an existing repository, split it into two repositories, one recent and one historical, and then we’ll see how we can recombine them without modifying the recent repositories SHA values via replace.

Zhentar posted:

AutoCrLf handling is, at best, poor. It will mark files as modified immediately after checking them out, which will interfere with a lot of operations (no switching for you).

ToxicFrog posted:

The problem he refers to is not with the editor, but with git itself. It's possible to get into a situation where the following happens:

- you check out a commit
- git fucks up with the CRLF conversion somewhere
- now git thinks all your files are modified because the line endings differ
- you can't switch branches or anything because git thinks everything is modified even though it isn't

Personally, I haven't observed this behaviour recently, but then, I haven't used git on windows recently either.

Lysidas posted:

I've seen this happen and I believe I have an explanation for it. I would guess that your repository contains files with CR+LF line endings (i.e. the actual content of the blob objects).

If core.autocrlf = true, Git will translate everything to a CR+LF line ending on checkout. However, since it would be committed with LF line endings instead of the CR+LF in the current commit, it's marked as modified (even after a git reset --hard or git stash).

Finn Arne Gangstad <finnag@pvv.org> posted:

autocrlf: Make it work also for un-normalized repositories

Previously, autocrlf would only work well for normalized
repositories. Any text files that contained CRLF in the repository
would cause problems, and would be modified when handled with
core.autocrlf set.

Change autocrlf to not do any conversions to files that in the
repository already contain a CR. git with autocrlf set will never
create such a file, or change a LF only file to contain CRs, so the
(new) assumption is that if a file contains a CR, it is intentional,
and autocrlf should not change that.


The following sequence should now always be a NOP even with autocrlf
set (assuming a clean working directory):

git checkout <something>
touch *
git add -A . (will add nothing)
git commit (nothing to commit)

Previously this would break for any text file containing a CR.

(commit message continues, but the rest isn't really relevant here)

epswing posted:

I should have clarified that I'd have a clone specifically for accepting changes. In fact I could have as many clones as I have pushing developers, each hg serveing on a different port.

Argue posted:

What's the best way of working with a project with a number of local-only configuration changes in git? Right now I have a branch that i continually rebase and never commit, but that's kind of a pain. I can't .gitignore them because some of the files have already been versioned. I can git update-index --assume-unchanged them, but git stash fucks things up when I do. Anyone have any other hints?

CHRISTS FOR SALE posted:

Hey git experts, I installed git on my jailbroken iPhone, and I'd like to know why I can't clone repos. Here's what happens when I try to: http://gist.github.com/608718

Yakattak posted:

For some god drat reason, git isn't making commits when I merge . For instance, I'm on master and I want to merge in issue3.

git merge issue3

That by default is supposed to make a commit that's like "Merge branch issue3" or something along those lines. However, such a commit never appears in my log, and it really isn't committing the merge. I've tried doing git merge --commit issue3 but still no commit. I'm on Mac OS X and git version 1.7.2.3.

Yakattak posted:

Yeah it does fast forward. What are the drawbacks to not fast forwarding?