Distributed systems fit very few development models.
[snip]
Not true in my experience. Every place I’ve worked in the last couple
of years has had to deal with developers that don’t always have
online access to the repo, or are in locations where connectivity
sucks so badly to their home location that it might as well not exist.
In fact every place I’ve every worked ever has had those problems -
its just that we only had solutions recently
Don’t get my wrong. I love Subversion. My home repo has been running
it for years and I’m in the process of moving $work over to it.
But I’ve been using SVK to as my primary client to access those
repositories for ages - and I wouldn’t want to go back to not being
able to commit on the train
People say that distributed systems have cheap branching, but I find
that very hard to believe, since (at least in the ones that I’ve
tried, and I have a hard time imagining how others would differ) the
branches are physical copies in a different location. That’s cheap for
the making, yes, but your total storage cost goes up (since none of
the advantages of having a single repository can be found) and it then
becomes possible to lose branches from your repository (cf fragility
above).
I have actually given that some thought. While not the case presently,
I think eventually this will become a mute point. Ultimately file
systems themselves will manage data redundancy. I think of it as
“holographic” memory. I don’t know why exactly as it has nothing much
to do with actual holographs, but it sounds cool
For fun I started writing a version control system in Ruby just to get
a better understanding of the concepts. Turns out not to be so hard
really --at least for a simple model.
In any case, as far your advice. I’m taking it, but with Matz’ twist.
My two main projects consist of many subprojects. I figure I can use
Subversion on the project as a whole, but Git on each subproject. Well
that’s the theory. Let you know how it goes.
On Thu, Mar 15, 2007 at 04:26:52PM +0900, Trans wrote:
becomes possible to lose branches from your repository (cf fragility
above).
I have actually given that some thought. While not the case presently,
I think eventually this will become a mute point. Ultimately file
systems themselves will manage data redundancy. I think of it as
“holographic” memory. I don’t know why exactly as it has nothing much
to do with actual holographs, but it sounds cool
The term “holographic”, in reference to data storage and similar
subjects, refers to a three dimensional indexing system. The term
“holographic memory” is already in use, generally involving
next-generation storage technologies that involve high density data
storage indexed three-dimensionally in photopolymers or crystalline
structures.
While I’m waxing pedantic, I may as well point out that the word you
wanted was probably “moot”, not “mute”.
I think eventually this will become a mute point. Ultimately file
systems themselves will manage data redundancy. I think of it as
“holographic” memory. I don’t know why exactly as it has nothing much
to do with actual holographs, but it sounds cool
As someone who works in the storage and backup industry, it will not
be a moot point.
For fun I started writing a version control system in Ruby just to get
a better understanding of the concepts. Turns out not to be so hard
really --at least for a simple model.
That’s actually what people think; it isn’t, in fact, as simple as
people think it is once you start scaling. Git works for Linux because
it fits that specific development model. Other systems generally have
to be more flexible.
becomes possible to lose branches from your repository (cf fragility
“holographic memory” is already in use, generally involving
next-generation storage technologies that involve high density data
storage indexed three-dimensionally in photopolymers or crystalline
structures.
Thanks. I’m aware. I’m using the term loosely, basically based on
concepts drawn from the book “The Holographic Universe” --the idea
that something thing can be in two different places at the same time.
I also view the the human brain something like holographic storage
using a form of reference and signal interference. In any case, I take
your point. I’m sure a better name already exists --I just don’t know
what it is.
While I’m waxing pedantic, I may as well point out that the word you
wanted was probably “moot”, not “mute”.
Yep. I make that silly mistake all the time. But I’m a fan of Mark
Twain for more than one reason.
Developer A is working on a major task. He has already changed a lot
of software locally. Now A gets aware that he needs B doing some
modifications in some other modules where B is the real expert.
Neither A nor B can propagate his own changes solely, because that
would break the build for all other developers. This is a normal
branch situation, but the branch situation has been recognized very
late. In addition A and B have to work some more time on the common
task, which means that they have to interchange and synchronize their
software releases several times without disturbing the others.
I’m just learning SVN, but can’t this problem be handled as follows:
Create a branch in the repository
Developer A uses svn switch to associate their local files with the
new branch
Developer A commits their changes to the branch
Developer B checks out the branch
I’m not trying to make any point re: distributed vs centralized
repositories
I’m just trying to determine if I understand how this might be
handled in SVN.
working offline is, with the exception of maybe a short stint on a
plane or train, not that common nowadays.
Working offline is not the only situation where a distributed version
control system may be better. How about the following situation.
Developer A is working on a major task. He has already changed a lot
of software locally. Now A gets aware that he needs B doing some
modifications in some other modules where B is the real expert.
Neither A nor B can propagate his own changes solely, because that
would break the build for all other developers. This is a normal
branch situation, but the branch situation has been recognized very
late. In addition A and B have to work some more time on the common
task, which means that they have to interchange and synchronize their
software releases several times without disturbing the others.
In a distributed system A and B just pull from each other as often as
they need to get the task done. Full propagation (resp. integration,
in a central system) will follow then, but not earlier.
So I’m wondering, what’s so special about SVN as opposed to the other
people such absolutes. So please, enlighten me.
So consider twice putting him into your kill file.
And yes of course Austin you have the right to holler at me, I was
quite harsh…
I know very well who he is. I don’t really care who he is if he makes
a large and absolute claim w/o backing it up. No special cases for
contributors either. I don’t think the acts are mutually exclusive.
This is one of the most beautiful things about the Ruby community. The
fact that some people even question Matz sometimes about his thoughts
and proposals is a sign of good health. No blind worship to be found
here please.
Now given that, I wasn’t about to kill-file him. I don’t mind just
archiving or deleting email I don’t like. Kill-filing seems to be a
bit far for most cases (Ilias might have pushed that line though
). He did an excellent job replying to my original concerns and made
his claim fair.
While I didn’t really agree with what he would do in my cases, I found
it much more logical once he put his position into the picture. It
rather enriched the conversation in my opinion but w/o that, it really
put a dull spin on things leaving a void of an answer just sitting
there.
A lot of people have my respect and thanks. Austin is one of them. I
will still try to play a fair game here still. Holler at me and call
me a troll if I don’t.
don’t transfer there.
I think it is only fair that you share why if you plan on telling
BUT he is a very valuable contributor.
fact that some people even question Matz sometimes about his thoughts
it much more logical once he put his position into the picture. It
rather enriched the conversation in my opinion but w/o that, it really
put a dull spin on things leaving a void of an answer just sitting
there.
A lot of people have my respect and thanks. Austin is one of them. I
will still try to play a fair game here still. Holler at me and call
me a troll if I don’t.
Why would I do that? It is rather me who is wrong, I actually thought
that you are a newbie, what a memory I have, and I thought it might be
a good occasion to say what I think and warn someone not to lose vital
information.
So I just made a fool out of myself, great.
I can only apologize for the misjudgment of the situation…
I do that quite often though lately
Solid Darcs Faster
Popular Stronger
Supported Better
Not that Darcs hasn’t been good to me.
T.
I would agree with a picture like that
I mostly only check out projects, and recently I saw some that switched
to git.
From the checkout/compile point of view git is pretty much the same as
cvs. But once I had to make a modification it became different. In the
end I found working with the modifications easier and cleaner.
However, I would be very disappointed if I found myself on Windows and
could not use git because of that.
The possibility of working offline is important for people who have
experience with crappy net coverage. I would count myself in, but I
understand that in some places such issues are nonexistent.
It looks like the distributed systems are new and more powerful which
means people have to get used to it. And many probably never will.
Also some features like crossplatform support have to be ironed out.
So I would guess the only reason to use them right now would be
experimenting or some features that are not easily obtained elsewhere.
I’m not sure what you’re reading, Robert, but in no way am I a Unix
* [email protected]
Fisrt of all thx for replying in this cool way I appreciate.
Sorry Austin if I do not read your mails carefully enough, I will try
to change this.
But I was pushed by the rather err aggressive wording of yours to come
to that conclusion.
If that conclusion was jumped you did very well to tell me nicely as
you are very credible in this way.
I freely admit that there is an OS that I hate, maybe I should shout
that out loudly even if it is politically incorrect instead of
compensating by believing that others hate Linux/Unix.
In the end it is me who behaved trollish here, kind of some old untold
frustration about somebody hollering at my beloved Linux/GNU/Cygwin.
I really appreciate the way you were handling this…
Austin a TROLL??? Well maybe he has adopted a troll like language but
I believe that you should see the context of all his contributions.
I defend him because I dislike him a lot and I find his Unix hatery
quite boring.
BUT he is a very valuable contributor.
Hatery?
I’m not sure what you’re reading, Robert, but in no way am I a Unix
hater. At work, I’m now running Ubuntu as my primary desktop (with
Windows as a VM) and have switched to OS X at home. I develop
professionally for Linux, AIX, Solaris, and HP-UX – and Windows. What
I refuse to do is to accept Unix-only solutions for things, because
that’s just chauvinism that has no place in Ruby, IMO.
I’m not sure what you’re reading, Robert, but in no way am I a Unix
hater. At work, I’m now running Ubuntu as my primary desktop (with
Windows as a VM) and have switched to OS X at home. I develop
professionally for Linux, AIX, Solaris, and HP-UX – and Windows. What
I refuse to do is to accept Unix-only solutions for things, because
that’s just chauvinism that has no place in Ruby, IMO.
Yes, port to such alien environment like WIndows is the litmus test of
portability
As one should not accept solutions that “work for the 90% of users”
(on Windows only), one should not accept solutions that exclude about
half of the users (the Windows users).
Professionally, I use subversion, though my team is looking to migrate
to something that does a better job at branch management and merging.
I have been thinking a lot about this too; the rule about not checking
in broken code seems to mitigate some of the agility that I’d like to
have. If I make progress and check in a branch, then I can delete what
I damn please in my further attempts to get it working. I will always
have those revisions to start from if it turns out my deleting was too
hasty. If I keep it local until it’s passing tests, I don’t have that
(but I can often approximate it by commenting lines out).
I plan to do a lot of branching for this reason. I have noticed,
though, that it is done somewhat sparingly in many of the repos I’ve
seen. Perhaps this is primarily related to project maturity, software
type, community circumstances. But I wonder if open source would be
that much more agile if the casual branching I described was more
common. It could be a bit like putting heads together to get it
working, begging feedback and brainstorm at more steps along the way,
rather than waiting until the code works to check in. Conversely, if
branching and merging is difficult enough that this luxury would rather
slow down the team, does the issue seem like one that can be addressed
in a future release, or is it an unavoidable consequence of svn’s other
features? Mostly rhetorical here.
Last thing. svn has a new sync feature. Does this make it [more]
usable as a distributed repo?
-Mike
[-just got hired through workingwithrails.com; extremely humbled to join
the ranks of professional rubyists!]
You might want to consider using SVK as your client (if you’re happy
using the command line). It’s a distributed system built on top of
subversion - so you can mirror subversion repos locally and push/pull
changes between your local copy and the main one.
I’ve been using it for about a year as my primary way of talking to
subversion and have been very happy with it.
Adrian, I’d love to hear more about your workflow. Could you give an
example of how you use this set-up for things like branching and
merging?
have those revisions to start from if it turns out my deleting was too
hasty. If I keep it local until it’s passing tests, I don’t have that
(but I can often approximate it by commenting lines out).
[snip]
You might want to consider using SVK as your client (if you’re happy
using the command line). It’s a distributed system built on top of
subversion - so you can mirror subversion repos locally and push/pull
changes between your local copy and the main one.
I’ve been using it for about a year as my primary way of talking to
subversion and have been very happy with it.
Adrian, I’d love to hear more about your workflow. Could you give an
example of how you use this set-up for things like branching and
merging?
Assuming $R is my “master” subversion repository I do something like
this
At the start of a project set up a mirror…
svk mirror $R/project/foo/trunk //foo/trunk
… and a local branch
svk cp //foo/trunk //foo/local -m ‘a local branch for local folk’
Check out a working copy into the foo directory
svk co //foo/local foo
Pull changes down from the central server
svk pull foo
I can then merrily work away in my local foo working copy committing
to my local branch on my local machine. When I want to push my
changes back to the central server I do
svk push --verbatim foo
(The --verbatim bit reproduces the commits you made to the local repo
on the remote one, rather than merging them into one big commit.
Makes it easier to track changes)
things up to date. Of course, that isn’t to say that avoiding merge
work always works either.
With all of this talk about SVN vs. anything not CVS, I would love to
see some ideas of how one could apply an svn interface to an existing
distributed tool. Some get close but maybe someone should make a
centralized “porcelain” for git? I don’t see any reason you couldn’t
implement a good portion of behaviors people seem to like.
I’m just catching up on some old email (so my comment may be far off the
mark
(or out of date)), but you (anybody might want to look into svk (try
googling for it).
I haven’t tried it, but it was recommended to me as sort of a front end
that
would let me:
use svn type commands
maintain a local and remote repository (i.e., distributed)
and the remote repository could be a variety of things, including
CVS,
SVN, Darcs, and …?
T.