[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Some advice and protocol would be appreciated.

From: Files <files_at_poetryunlimited.com>
Date: 2003-09-23 15:42:50 CEST

Sander Striker (striker@apache.org) wrote:
>
>When not sure, ask!
>

I did ask how to synchronize between the latest release and the trunk for my
mandrake section - which incidentally patches some configuration files etc, which
can change w/ no notice.

I had asked if we had a staging area for release branches etc, and if there was a
centralized area where I could test my changes, etc..

I guess I asked the wrong question. KFogel kept telling me to just make the changes
in the trunk. I guess I just wasn't getting it.

>> Since I work at home on subversion and sometimes from work, there needed to be a
>> way for me to transmit changes in-progress that might not compile successfully.
So I
>> was using the branches to carry that out.
>>
>> I am also used to keeping an offisite copy up to date so work is not lost, hence
I
>> commit to the branch when I need to save intermediate results.
>
>You've created at least 2 branches: 'mdk-test' and 'silent'. Surely you could
>have done the silent build testing in your working copy.

Umm. No. The silent branch is to show you guys how to make the stock system silent.
It's not got anything to do w/ Mandrake. I have no official sanction. Since Julian
seemed somewhat interested in seeing the stock build be silent, I figured, I would
attempt to backport what I had done for the Mandrake build but in a different
context - one that could be turned off on the fly with a switch that didn't require
an additional Makefile to be changed.

>> Being the new kid on the block, perhaps it's best if you *tell* me how you want
me to
>> treat the branches.
>>
>> I am not used to an environment where you can commit to the trunk when something
>> is in flux and not ready for production.
>
>We don't do that. trunk must compile, work and pass the test suite at all
>times.

Ok. Just got me confused when I heard, "commit your changes to the trunk.". Left me
with a bunch of questions still unanswered.

>Anyway that solves your problem without cluttering our inboxes with commit
>mails. Be that putting things on a laptop, floppy disk, sending by mail,
>putting it on a local fileserver, a local copy of subversion, ...

So you're saying you guys actually watch the revision numbers? Gotcha. Sorta like
someone counting phone calls. Oh wait. You all get emails every time someone
commits? That's where this is all stemming from. Understood. Had completely
forgotten about that feature altogether.

>Copies are cheap, yes. Peoples time however, is not. And when I see branches
>being created and big blocks of commit from one person, my personal alarm bell
>tells me to watch what is going on. I am very comfident that I am not alone in
>this.

I suspect that had it not been so close to the 9/21/03 date, you would not have seen
as many. I was concerned I had left something undone. I will be more careful.

>At the very least, read HACKING.

Been a while. Will reread. BTW, is there a switch to do per file log comments?

>The usual course of action new committers take is to watch how things work.
>Basically all committers came in after they had already produced a few
>patches and been around for a while. We decided to lower the bar for
>commit access on the non-core code, expecting the old trend to continue.
>Maybe that was a mistake, I don't know.

I don't know either. Maybe there *could* be a development repository somewhere? I
dunno.

Seriously, shouldn't there be an environment where you can commit often without
geenrating concern? Maybe I'm thinking of a pie in the sky. In the meantime, I'm
going to try to create a private repository or *something* that allows me to share
between my two environments, track my changes but don't upset everyone because the
revision numbers keep changing too fast. My own damn luck that I can't trust
computers between when I switch them on and off - lost too much too many times.

Let's see if things get better. And go from there.

Shamim Islam
BA BS

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 23 15:43:45 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.