| |||||||||||||
A proposed Subversion vision and roadmapA proposed Subversion vision and roadmapPosted Apr 3, 2010 15:50 UTC (Sat) by stumbles (guest, #8796)Parent article: A proposed Subversion vision and roadmap I'm just curious how git cannot perform, offer or other wise do these things;
1. They need centralization.
(Log in to post comments)
A proposed Subversion vision and roadmap Posted Apr 3, 2010 16:21 UTC (Sat) by dmitrij.ledkov (subscriber, #63320) [Link]
Hmmm let's see bzr supports central control and FS ACL's it supports svn checkouts where your
commit cannot rewrite history on the server and cannot divert mainline history. It supports central repository as well.
So if you want or need "coorporate theatre" and still have no pain DVCS merging choose bzr.
I'm very confused which 2 DVCS were picked? I guess git but I can't place the other one bzr, hg,
A proposed Subversion vision and roadmap Posted Apr 3, 2010 16:32 UTC (Sat) by bboissin (subscriber, #29506) [Link]
"I'm very confused which 2 DVCS were picked? I guess git but I can't place
the other one bzr, hg, darcs, monotone?" hg
A proposed Subversion vision and roadmap Posted Apr 3, 2010 16:38 UTC (Sat) by cowsandmilk (guest, #55475) [Link]
from my own experience, I would guess hg, but bzr has some pretty big deployments (launchpad...)
A proposed Subversion vision and roadmap Posted Apr 5, 2010 15:22 UTC (Mon) by bronson (subscriber, #4806) [Link]
The Launchpad source tree is 150MB, full history is 280MB. That's tiny!!
Judging by the icons on http://bazaar.canonical.com/en/ it looks like MySQL and GNU Emacs are the biggest bzr projects, but they're miniscule by KDE/Gnome/Moz/etc standards.
Does bzr have a win that's not shown in those icons?
A proposed Subversion vision and roadmap Posted Apr 5, 2010 16:20 UTC (Mon) by csenger (guest, #65002) [Link]
>> from my own experience, I would guess hg, but bzr has some
>> pretty big deployments (launchpad...)
> The Launchpad source tree is 150MB, full history is 280MB.
Launchpad with bzr as a deployment is more interesting than the size of the source code of launchpad itself. It runs (taken from their frontpage) more than 17.000 projects, so there are many bzr users.
> Judging by the icons on http://bazaar.canonical.com/en/ it
I guess the biggest project is Ubuntu, but I'm sure they do not use one shared repository.
> Does bzr have a win that's not shown in those icons?
They are nice guys who behave friendly.
..Carsten
A proposed Subversion vision and roadmap Posted Apr 6, 2010 20:12 UTC (Tue) by vonbrand (subscriber, #4458) [Link]
How many projects are the on repo.or.cz, gitorius, github, codaset, under git at Sourceforge and similar sites? Just github claims some 150,000 public repositories! This surely dwarfs any
A proposed Subversion vision and roadmap Posted Apr 8, 2010 8:28 UTC (Thu) by csenger (guest, #65002) [Link]
> How many projects are the on repo.or.cz, gitorius,
> github, codaset, under git at Sourceforge and > similar sites? Just github claims some 150,000 public repositories!
That wasn't the question, and I'm not talking about X having the most users or Y having the hugest deployment. The root of this discussion was the question what may be the second mentioned dvcs. I'm sure it's mercurial, but it's important to see that bzr nonetheless has a big userbase.
> This surely dwarfs any bzr stuff on Launchpad...
Funny to see that always someone needs to state that he has the biggest.
A proposed Subversion vision and roadmap Posted Apr 6, 2010 19:18 UTC (Tue) by vonbrand (subscriber, #4458) [Link] If you have the right access to the repo, you can falsify history. Hell, you can create any history you want. A centralized system is more dangerous, as it is a single point of failure here. With a bit of massage to git (see the ProGit book, and in particular gitolite) you can restrict who can rewrite what history, so this is long not an issue anymore.
A proposed Subversion vision and roadmap Posted Apr 3, 2010 17:18 UTC (Sat) by RCL (guest, #63264) [Link]
By no means git is simple.
A proposed Subversion vision and roadmap Posted Apr 3, 2010 17:26 UTC (Sat) by marcH (subscriber, #57642) [Link]
> By no means git is simple.
I blame the index
But nothing else. Or is there?
A proposed Subversion vision and roadmap Posted Apr 3, 2010 17:29 UTC (Sat) by Kit (guest, #55925) [Link]
In my experience, I've found git was extremely simple to use if your requirements were fairly simple. On the other hand, I found SVN much harder to use and setup when dealing with tiny, entirely personal projects. With git, I could start out by just having the 'repository' hosted entirely within the actual project directory (i.e. no real setup), without needing to setup/use any other servers. And then, if I later change my mind, adding the project to gitorious with the full history was quite simple.
Probably the most complex aspect of git I've found is that the official tutorial I used (primarily as a cheat sheet to help me remember the commands) seemed to keep moving locations on the kernel.org server.
A proposed Subversion vision and roadmap Posted Apr 3, 2010 19:29 UTC (Sat) by fperrin (guest, #61941) [Link]
> On the other hand, I found SVN much harder to use and setup when dealing
> with tiny, entirely personal projects.
mkdir SVN && svnadmin create SVN && svn co SVN .
Yes, that's more work than git init && git add *.c, but "much harder" ?
A proposed Subversion vision and roadmap Posted Apr 3, 2010 21:37 UTC (Sat) by heipei (guest, #63821) [Link]
You don't seem to be using git the way I do. Let me give a little example:
1. Download some non-versioned source from a website, untar it into dir
The point is that you don't have two locations for one tiny thing (a repo and a working copy). Also it
By the way, if you just want to keep track of very simple changes to a pristine codebase, you can
Offtopic svn tricks (was: A proposed Subversion vision and roadmap) Posted Apr 4, 2010 1:24 UTC (Sun) by cesarb (subscriber, #6266) [Link]
You do not need to copy your files to the empty working copy, you can just _move_ the hidden .svn directory from the empty working copy to where you are already working and rmdir the now-empty directory. Then just add and commit as usual.
Offtopic svn tricks (was: A proposed Subversion vision and roadmap) Posted Apr 4, 2010 7:35 UTC (Sun) by fperrin (guest, #61941) [Link]
cesarb:
> You do not need to copy your files to the empty working copy, you can just _move_ the > hidden .svn directory from the empty working copy to where you are already working and > rmdir the now-empty directory.
Or even simpler, as I did in my exemple, just "svn co file:///$PWD/SVN ." while being in the
heipei:
Yep, I forgot about that. As I did above, replace the checkout step with "svn co file:///$PWD/SVN ."
A proposed Subversion vision and roadmap Posted Apr 3, 2010 22:06 UTC (Sat) by fuhchee (subscriber, #40059) [Link]
"By no means git is simple."
OK, then how about building (yet another) simple front-end for git?
A proposed Subversion vision and roadmap Posted Apr 4, 2010 15:28 UTC (Sun) by drag (subscriber, #31333) [Link] I have had zero experencies with source code control and I found Git much easier to use then anything else. I've tried SVN and CVS in the past, but they were just too difficult.git init git add . git commit -a boom, boom, and boom. Done. I don't have to worry about renaming stuff, moving files around, moving directories around, deleting files, deleting directories, etc etc.. There is very little with git that prevents me from using a git repo as any other directory. The only major problem I keep seeing people having with git is the lack of central repository. It's very easy to have a central repository with git though... you just setup a repo, call it 'The Central Repository' in your mind and just commit and pull to it and never use it directly. The biggest problems I've had with Git involved pushing from one repository to another that have been seperated for a long time. Having a 'central' git repo that is push/pull only solves that for me. I still use the 'distributed' stuff since I will commit dozens a time a day while working online or offline, or behind firewalls, and on multiple disconnected machines. Hell, I would not mind running a commit every time I do ":wq" on a vim session.
A proposed Subversion vision and roadmap Posted Apr 5, 2010 4:32 UTC (Mon) by Kit (guest, #55925) [Link]
>I have had zero experencies with source code control and I
>found Git much easier to use then anything else. I've tried >SVN and CVS in the past, but they were just too difficult.
This was exactly my experience. The (crappy) documentation I could find for SVN (I didn't bother with CVS, since it'd already been supplanted by SVN for a while by then) assumed I'd be using SSH or Apache to connect to the repository, and I found the SSH setup to be horribly ugly for a purely local workflow (I didn't even care to bother with Apache, that seemed a bit silly to me).
> boom, boom, and boom. Done.
Those commands are more than enough to get you started on a personal project, and it's fairly simple to pick up the other stuff as your needs expand (I was shocked at how simple branching was... I actually thought I had done it wrong since I'd read so much about how poorly SVN handles it). Plus, being able to make commits even when offline or when you don't want to make them public yet (but you don't want one massive commit containing a crap load of work all over the code base) is easy as hell with git (you just commit and don't push!).
A proposed Subversion vision and roadmap Posted Apr 3, 2010 20:04 UTC (Sat) by ikm (subscriber, #493) [Link]
> 3. They need meaningful path-based authorization.
Erm, how would you do this in Git exactly? Apart from creating a set of separate repositories, which is not it.
A proposed Subversion vision and roadmap Posted Apr 3, 2010 20:17 UTC (Sat) by engla (guest, #47454) [Link]
Using hooks in the central repo that check the changes (vs ssh key used) before accepting
pushes. It's something that can be easily configured, but it's all possible.
A proposed Subversion vision and roadmap Posted Apr 3, 2010 20:19 UTC (Sat) by engla (guest, #47454) [Link]
I meant, "not" easy to configure.
A proposed Subversion vision and roadmap Posted Apr 3, 2010 20:24 UTC (Sat) by ikm (subscriber, #493) [Link]
How are you going to only pull what's authorized path-based? Does git's history work this way at all?
A proposed Subversion vision and roadmap Posted Apr 3, 2010 22:10 UTC (Sat) by joey (subscriber, #328) [Link] git's pre-receive hook can see the old and new revisions, and from that, every change that is being made can be examined. When I was implementing untrusted git commits to ikiwiki, using that to reject pushes that contained any sort of disallowed change was not that hard to do.But this is limited to accepting the whole set of changes, or rejecting everything. Well, I suppose you could have the hook fail and then go commit the subset of changes that were acceptable. In theory. In practice, if the user has made many changes, their whole push could fail due to any change the hook dislikes, and they would then most likely need to rewrite their history to get a clean set of changes that the hook accepts. There is another infelicity if the user pushes using git-daemon. (Ie, a purely anonymous push.) The daemon uses a protocol that did not, last I checked, allow any error messages printed by the hook to be displayed to the user. So it can be hard to tell why your push was rejected. Sorry for the TMI.
A proposed Subversion vision and roadmap Posted Apr 3, 2010 22:14 UTC (Sat) by ikm (subscriber, #493) [Link]
Yes, you can limit write access, but what about read access? Can you authorize only certain paths to be pulled?
A proposed Subversion vision and roadmap Posted Apr 3, 2010 22:13 UTC (Sat) by engla (guest, #47454) [Link]
You are right, selective read access is fundamentally impossible with Git.
Selective read access Posted Apr 4, 2010 7:05 UTC (Sun) by smurf (subscriber, #17840) [Link]
This is simple. Create separate repositories.
Granted that linking the stuff together via submodules could be easier, but then setting up a SVN repo to do the path-based stuff isn't exactly child's play either.
Selective read access Posted Apr 4, 2010 7:36 UTC (Sun) by ikm (subscriber, #493) [Link]
> This is simple. Create separate repositories.
It's not the same thing. When you have just one repository, a lot of things are simpler, like e.g. tagging, browsing history etc. When you have multiple repositories, you have to repeat each operation for each of them. Or, imagine e.g. you had your repository for some time, and then suddenly you need to grant read/write access to just a part of it to someone. With svn, this is simple. With git, well, impossible.
> setting up a SVN repo to do the path-based stuff isn't exactly child's play either
I disagree. Actually, it is.
p.s. I don't understand the need to defend GIT. Yes, it's awesome, and no, it's not universal. Why not just accept that?
Selective read access Posted Apr 4, 2010 8:30 UTC (Sun) by smurf (subscriber, #17840) [Link]
I'm not exactly defending git. I just happen to like it better than the other DVCSes.
My real rationale for writing here is that I _really_ dislike non-distributed VC systems, for the simple reason that I can't do my own version-controlled changes without either asking for commit access or re-importing the stuff into my own VCS. "git svn" to the rescue
Granted that giving partial r/w access to somebody after the fact may not be particularly easy with git, but give me a few hours and I'll write a script to convert a subtree into a git submodule, with a copy of the relevant part of the commit history. Problem (mostly) solved.
A proposed Subversion vision and roadmap Posted Apr 4, 2010 19:27 UTC (Sun) by engla (guest, #47454) [Link]
I think however that it is not that fundamentally impossible that the next version couldn't support
selective clone omitting certain directories. Narrow checkout code plus newly written clone/fetch should do it.
A proposed Subversion vision and roadmap Posted Apr 5, 2010 17:38 UTC (Mon) by iabervon (subscriber, #722) [Link]
At one point, someone did some work on having git able to represent "at this path, there's some content I don't have in my working directory, but whose hash I know." With that, you can make commits where you don't have what's at the location but you can make commits that don't change it. I'm not sure whether this ever got into the mainline, though. There would also need to be some work to track "at this path, there's some content I don't have, and it's a directory whose hash I know", and some work to have git be okay with not having the content available at all (it was only made happy with not having the content in the working directory), and having the server know to not give certain content to certain users. Of course, git will never be any good at the situation where you're not allowed to see file A, file A is in a directory that you can see other things in, and file A's content is identical to some content of some other file A, which you can see; or, in general, situations where the big secret is when a file changes, not what's in it.
A proposed Subversion vision and roadmap Posted Apr 4, 2010 1:13 UTC (Sun) by jengelh (subscriber, #33263) [Link]
>1. They need centralization.
Git has it. (Look what kernel.org is to us :-)
>2. They need control.
With git you have total control as a maintainer. So much control that you can reject an entire pull request just because one single file has a whitespace error. Or put more realistically: nothing goes into your repository without your consent. That's control.
>3. They need meaningful path-based authorization.
Path-based authorization is a hack for a management flaw (throwing projects together into a single repository). Suppose the filesystem maintainer only had write rights to fs/ that would most likely suck when there's an API change to be made that affects files in mm/. Doing two separate commits would introduce non-compilable commits into a bisect workflow. So people should just actually get together and actually talk about their changes and not just commit in the hope that it will be ok. That way, Git actually enforces that you get a handful of the important eyeballs that are said to make bugs so shallow (assuming a project that's not done de-facto-solo).
>4 They need simplicity.
I won't call Git outright simple, but the way it works makes it simple in the long run. Annotating (i.e. rebase -i + reorder + edit) commits something that is, at least was, last time I looked, "impossible" (read: infinitely infeasible) in SVN is one example not to miss in Git. SVN repositories seem to generally have a higher percentage of commits that (try to) fix up mistakes things post mortem again and again:
------------------------------------------------------------------------
- still not correct.
------------------------------------------------------------------------
- and again...
- fixed: M_DrawSlider did not print the correct value if the slider's minimum was not 0.
A proposed Subversion vision and roadmap Posted Apr 5, 2010 9:08 UTC (Mon) by oak (subscriber, #2786) [Link]
What was worse for me that when (I had to use SVN and) did "svn log" on a
directory, I got unexpected results. SVN doesn't show changes for all the files below that directory when I ask for a log. That was quite a shock.
Maybe I wasn't using the correct command/option, but SVN is supposed to be
[1] http://edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf
PS. Regarding the repository size. There was comparison of sizes a few
[2] The generic link to the this great version control blog is:
Many of the posts there are several years old, but I think still
A proposed Subversion vision and roadmap Posted Apr 5, 2010 14:10 UTC (Mon) by fw (subscriber, #26023) [Link]
Those fix-up commits aren't pretty. But I've seen Git histories which contain merges of both the rebased and non-rebased versions of development history. This is far worse. When such things happen, it can become very difficult to extract any relevant information from the DAG, severely limiting its usefulness.
A proposed Subversion vision and roadmap Posted Apr 6, 2010 23:04 UTC (Tue) by vonbrand (subscriber, #4458) [Link] You shouldn't publish rebased branches (or any branches with rewritten history that was seen before). In true Unix tradition, git provides plenty of rope to shoot your feet with...
A proposed Subversion vision and roadmap Posted Apr 6, 2010 23:14 UTC (Tue) by jengelh (subscriber, #33263) [Link]
And SVN provides the gun to hang yourself with? :-)
A proposed Subversion vision and roadmap Posted Apr 7, 2010 17:19 UTC (Wed) by cry_regarder (subscriber, #50545) [Link]
One bright day in the middle of the night
two dead boys got up to fight back to back they faced each other drew their swords and shot each other
|
|||||||||||||