Bummer, either I can't find Byron's email address or it doesn't like me.... I'm trying to send these to you as well, Byron, so please don't think I'm only posting to the group
----- Forwarded Message ----
From: "MAILER-DAEMON@yahoo.com" <MAILER-DAEMON@yahoo.com>
To: edhillmann@yahoo.com
Sent: Tuesday, 23 January, 2007 11:56:48 AM
Subject: failure notice
Hi. This is the qmail-send program at yahoo.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<byron.brummer@livenation.com>:
207.230.143.145 does not like recipient.
Remote host said: 501 #5.1.1 bad address byron.brummer@livenation.com
Giving up on 207.230.143.145.
--- Below this line is a copy of the message.
Return-Path: <edhillmann@yahoo.com>
Received: (qmail 94612 invoked by uid 60001); 23 Jan 2007 01:56:46 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
b=ZIm2Xi7+JQOkV2TueQ0DWAX70W1saqhTDHqzMGsNfb/ze1ZBpBCu+bur7X/+4+xuz/zftTAatcxbcyehToeCKp41GqWgz5hvB4gk7HLL04+S0otqxnp18NVlTDgrTPylwvUtQXy8vVGIDPd9T4DSRu0DT0Oy/p+jDIquTDsJmGk=;
X-YMail-OSG: l2nkjE0VM1mskOwL6XwQ7ShrdFU7dpkz9k.GpNxDlzNNOH7Gv5Ho_OzZYiZKdNEduWFv715byPIcnfzpWsnkIIcAtWcQQ9mDxnh62GQIIzZjb7WSADkTBwnVN2LlptwSh6kT_xc3Iw10Eq1LNLgIoSDYVz3vuKygzVAK9H7qn4rzfMD5.mFBiEHPNHe1
Received: from [203.57.223.25] by web52413.mail.yahoo.com via HTTP; Mon, 22 Jan 2007 17:56:46 PST
X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7
Date: Mon, 22 Jan 2007 17:56:46 -0800 (PST)
From: Ed Hillmann <edhillmann@yahoo.com>
Subject: Re: Subversion tagging
To: Byron Brummer <byron.brummer@livenation.com>,
"L. Wayne Johnson" <wayne@zk.com>
Cc: users@subversion.tigris.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <763717.94068.qm@web52413.mail.yahoo.com>
> In an ideal world...sure.=0A=0A> In the real world you'll commit =
this changeset believing that yes,=0A> it contains all that's required =
for this particular fix. But then=0A> QA gets ahold of it and woops, i=
t didn't pass. So you revisit the=0A> fix, complete the part you misse=
d, and commit it. The process=0A> repeats, but now your nice tidy atom=
ic commit is spread across two=0A> revisions. By the time it actually =
gets through QA, user acceptance,=0A> and legal, it may actually includ=
e dozens of revisions...=0A=0A> What would you do instead? Roll back y=
our changes each time and=0A> try again from scratch so that when it fi=
nally passes it would be=0A> in a single tidy revision?=0A=0AFor what i=
t's worth, we have a ticketing system which is used to track what changes w=
ere applied for what fix. This existed long before we switched to Subversi=
on. So a ticket is raised which encapsulates a bug fix or enhancement requ=
est. There's development, and the ticket gets updated with which revisions=
were created with the changes.=0A=0AThe ticket gets tested, and lets say i=
t fails a test (theoretically :) ). The tester documents in the ticket the=
reasons for failure. More development ensues, we don't start from scratch=
, just record more in the ticket what subsequent changes were made. Rinse,=
lather repeat.=0A=0AWe at no time expect that all changes for a single tic=
ket are required to be represented by a single Subversion Repository revisi=
on. We have plenty of changes which are just too large for that. Even for=
simple one-file changes, we will have multiple revisions where that fix ma=
y be merge into various releases we have to support.=0A=0AThe ticket also t=
racks where the changes were applied (trunk and/or branches). As part of o=
ur process, we have a web application which extracts the changed files for =
a ticket (across all of the revisions defined for the ticket) so we can cod=
e review changes (using ViewVC for diffs, or also load the diffs into other=
file compare utilities).=0A=0AWith something like this, we don't expect th=
e version control repository to keep track of all this information: it's no=
t its job.=0A=0AWith iterative development, tickets are simply created for =
each tasks defined as part of each iteration. So, the final look of new fu=
nctionality may span across multiple tickets (where the functionality was r=
efined with each pass of the iterative wheel - a lot of times, waterfall pr=
ocesses don't fully define the requirement set).=0A=0ASo, I'd argue that th=
e scenario you're describing isn't best satisfied by demanding file-level t=
ags in Subversion. But I can only speak about the processes I've been expo=
sed to as well as what I find works for us. We have a ticketing system we =
can use, I don't know if you have one there which is available. There are =
some open source systems if cost is an issue (IssueZilla), but I wouldn't e=
xpect any versioning system to be able to contain all the information I nee=
d to track for any chance we do for our software for standards accrediation=
s.=0A=0A=0A=0A=0ASend instant messages to your online friends http://au.mes=
senger.yahoo.com
Send instant messages to your online friends http://au.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 23 02:58:48 2007