| |||||||||||||
A proposed Subversion vision and roadmapA proposed Subversion vision and roadmapPosted Apr 3, 2010 22:13 UTC (Sat) by engla (guest, #47454)In reply to: A proposed Subversion vision and roadmap by ikm Parent article: A proposed Subversion vision and roadmap
You are right, selective read access is fundamentally impossible with Git.
(Log in to post comments)
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.
|
|||||||||||||