On May 5, 2005, at 5:45 AM, Jacob Atzen wrote:
>> Currently, we all work out of a shared directory, making local copies
>> of files we're working on, then copying those back to the server.
>
> Could you describe this a little more elaborately? To me it sounds
> totally impossible to work on anything which includes code in this way?
> Doesn't your project contain code?
I could probably describe it more elaborately, but not because it's any
more complicated than that. To start working on a file, copy it from
the server. When you're finished, copy it back. It's a relative handful
of us, and we hardly ever work on the same files simultaneously.
Obviously, we feel the need to get organized about it, because I'm
prepared to take steps to provide for more advanced organization. But
it's hardly "totally impossible."
>> So... those of you with a mischievous streak... should I go for it?
>
> I agree with the people voting for "be honest about it" and not
> sneaking
> things in. If you sneak things in your colleagues will most likely lose
> some respect for you...
I think I asked for feedback from those with a sense of mischief and
adventure...
> There's one aspect of this whole source-control thing that (to my
> surprise) no one so far has touched upon: The problem of concurrent
> work
> on the same files. I'm not sure how you manage this in your current
> setup, but from my experience it's a pain even with small teams of 2-3
> people, copying files back and forth, making sure nobody is stomping on
> eachothers work. And this to me is the number one killer feature of a
> source control system like Subversion. The ability to work without
> having to worry.
Hmmm. So what you're saying is, we should maybe consider something like
this "version control" of which you speak? We've been sort of grunting
as we bang this rock against this other rock near this pile of leaves.
Is this "Subversion" better? Is there a mailing list I could maybe
subscribe to?
> To be able to help further we probably need to hear more details about
> your setup and also what position you take in the team.
I thought I posted a wordy reply to this effect in response to Ben
Collins, but I'm not sure it ever made it. The gist of it was this:
we're not the Army. If this is going to happen, it will be because I do
it, not because I ask for it to become some kind of policy. There's no
vertical hierarchy to stamp this down. The idea is to put it in place,
get the project organized, lay in some commits so that people can
follow a good example, and then work with everyone individually to
bring in their involvement. The query was in regard to minimizing the
disruption to everyone else. Perhaps I overplayed the secrecy angle,
but with a name like "Subversion," I'm not sure what you'd expect.
The square question might have been, "How might I deploy Subversion and
bring in the rest of my team incrementally?" The assumption is that
deployment can be either monolithic face-on style, or cooperative and
adaptive to the existing workflows of other contributors. I'm trying to
do this along the lines of the latter, that's all.
j
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 5 17:26:21 2005