User: Password:
|
|
Subscribe / Log in / New account

mercurial?

mercurial?

Posted Jun 18, 2013 14:27 UTC (Tue) by marcH (subscriber, #57642)
In reply to: Subversion 1.8.0 released by dskoll
Parent article: Subversion 1.8.0 released

For any git user, git svn is definitely the best SVN client ever.

Is mercurial's user interface actually simple enough to understand for non-technical users? That could be the best of both worlds. Almost.

http://steveko.wordpress.com/2012/02/24/10-things-i-hate-...


(Log in to post comments)

mercurial?

Posted Jun 19, 2013 3:40 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> For any git user, git svn is definitely the best SVN client ever.

That depends. How many commits are in the SVN repo? If it's a large repo, it's best to do the conversion once and then use that if you have multiple people working on it. If two people use different flags for "git svn clone", the repos are basically incompatible.

mercurial?

Posted Jun 19, 2013 14:42 UTC (Wed) by dgm (subscriber, #49227) [Link]

> If two people use different flags for "git svn clone", the repos are basically incompatible.

That should be no problem, as long as they use git as a SVN client. That means that the canonical repo is still the SVN one, so they only need to be compatible with SVN, not between them.

The nice thing is that they can still clone and fork each other repos, push stuff around and it will commit to SVN just fine. It's magic, if you ask me.

mercurial?

Posted Jun 20, 2013 0:36 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

The problem I had was that a coworker had a branch I wanted. It had a nice pile of commits and I would have just rather preferred to pull from his repo directly rather than having to do a format-patch or rebase --onto to get the patches in the same history as mine.

mercurial?

Posted Jun 23, 2013 22:34 UTC (Sun) by marcH (subscriber, #57642) [Link]

You are correct that git-svn is not as good as git.

It is still better than the native SVN client.

mercurial?

Posted Jun 20, 2013 16:54 UTC (Thu) by khim (subscriber, #9252) [Link]

If you use git-svn then you make life of all your coworkers miserable: svn attributes are ignored, renames/merges of files are often messed up, etc. And if your answer is "oh, that's not a problem, everyone else should just switch to git-svn too", then the question becomes: why bother with svn at all? If you want to use git-svn to grok some repo, then it's OK, but to contribute please use native svn client...

mercurial?

Posted Jun 22, 2013 15:31 UTC (Sat) by dskoll (subscriber, #1630) [Link]

If you use git-svn then you make life of all your coworkers miserable:

Not at all. Recall how I'm using SVN: as a repository for non-technical people to check in documents and have them in centralized version control. We're not using any of the advanced features of SVN and none of my coworkers even notices that I use git svn instead of svn directly.

mercurial?

Posted Jun 24, 2013 21:31 UTC (Mon) by khim (subscriber, #9252) [Link]

Recall how I'm using SVN: as a repository for non-technical people to check in documents and have them in centralized version control.

You mean they don't need to know about histories of their files? Why are you using such a complex tools as SVN, GIT, etc? Simple network share should suffice.

We're not using any of the advanced features of SVN

GIT-SVN is fundamentally incapable of keeping correct SVN history (just a recent example). Worse: it usually works and it's very easy not to notice a problem when you commit your file. But later, when you'll try to use SVN for the forensic work (this is what VCS is used for, right?) you'll find out that history of your project is scrambled up.

none of my coworkers even notices that I use git svn instead of svn directly.

Sure. For them the end result looks like a work of madman who copies files around randomly and changes them for no apparent reason. You can create something like this with SVN client, obviously, but in that case history is usually looks saner.

mercurial?

Posted Jun 25, 2013 7:48 UTC (Tue) by marcH (subscriber, #57642) [Link]

> You mean they don't need to know about histories of their files?

Even if *they* don't want to know, other people like him probably do.

It's quite frequent to have to force "non-technical" people to use version control. Worse, you'll even find some people still refusing to see the value of it even after using it for a long time.

Git is the very last solution you want to this type of problem.

mercurial?

Posted Jun 23, 2013 22:32 UTC (Sun) by marcH (subscriber, #57642) [Link]

> If you use git-svn then you make life of all your coworkers miserable:

In practice I've never seen anyone using git-svn getting noticed.

Yes I remember myself temporarily switching to the native SVN client to operate on SVN properties. However I never broke any with git-svn.

Maybe someone tried to blame the tool for his own mistakes?

mercurial?

Posted Jun 24, 2013 21:19 UTC (Mon) by khim (subscriber, #9252) [Link]

In practice I've never seen anyone using git-svn getting noticed.

Of course not! Other people notice problems, not git users! Just a recent example of this fundamental problem.

Yes I remember myself temporarily switching to the native SVN client to operate on SVN properties.

Unfortunately one of these "SVN properties" is information about history of a particular file. And if you don't need to know about different versions of your file then why are you using VCS in the first place?

mercurial?

Posted Jun 25, 2013 7:59 UTC (Tue) by marcH (subscriber, #57642) [Link]

I really did mean:

In practice I've never seen anyone using git-svn getting noticed by *SVN users*.

Your "recent example" link does not look related, did you copy the wrong URL?

In another post you seem to hint at file renames in a roundabout way. I would certainly avoid git-svn and switch back to a plain SVN client if I were to rename files "like a madman".

[In fact I avoid "madman renames" at all cost - with any client. Even when renames are tracked in the best possible way they *always* create pain no matter what]

> And if you don't need to know about different versions of your file then why are you using VCS in the first place?

Thanks for keeping the signal/noise ratio of this thread higher than this.

mercurial?

Posted Jun 25, 2013 15:50 UTC (Tue) by nye (guest, #51576) [Link]

>Your "recent example" link does not look related, did you copy the wrong URL?

I see what khim means:

That thread describes an example where a file has been mostly rewritten, and the new file is almost identical to an unrelated file elsewhere in the tree, because they are both so short that the license header constitutes the majority of the file.

Since git tracks the state of trees, there's no problem when you're using git natively. To send the changes to svn though requires that git generates a diff. The change to the file is so great, and the similarity to an existing file so high, that the diff it generates by default describes a copy of the other file followed by a change of the non-license part of the file, which is clearly a failure in git's move/copy detection heuristics and will produce nonsensical change history when imported to svn.

That said, it's arguably not too major a failure, because if you're looking at the diffs you're generating then you can see the problem immediately and can ask git to DTRT by setting the similarity parameter for the heuristic to something more appropriate. I don't know if git-svn makes that easy to notice in the standard workflow though, as I don't use it.

There are some fairly dodgy heuristics in git which can cause this kind of thing, and while we're looking at dodgy heuristics I might suggest that the similarity threshold could be a) dynamically adjusted according to the length of the file, and b) possibly altered to weight lines more heavily the further they are down the file, based on the reasoning that it's typically the beginning of most files (for code anyway) that tend to have a load of common guff that confuses the similarity detection.

mercurial?

Posted Jun 27, 2013 22:12 UTC (Thu) by marcH (subscriber, #57642) [Link]

In summary, to actually have happened this accident would have had to take:
- an idiot not having a single look at the commits he pushes, plus
- a lawyer forcing him to add a copyright header longer than the rest of the file.

Clearly the type of thing that happens everyday at the git-svn office.

Once again and more seriously: every single limitation of git-svn can quickly be worked around by temporarily (and rarely) switching back to the plain SVN client.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds