On Nov 20, 2006, at 13:00, Andy Peters wrote:
> On Nov 20, 2006, at 11:17 AM, Thomas Wicklund wrote:
>
>> This shows the problem with the current method. Why did you checkout
>> revision 100? Was it the head revision at the time? The main
>> repository I use is at around revision 20,000. A legacy
>> repository is
>> also at about the same revision number. The revision number probably
>> increments by 10-20 each day.
>
> Thanks for pointing this out! I agree; why are people concerned
> with checking out a specific (and probably outdated) revision from
> which they start to work? Sounds like it's better to create a
> branch (possibly from a tag) and start there, then merge back to
> the trunk.
I assumed one of these scenarios:
foo) I finish working on a feature, and end up committing revision
100. I send an email to the testing department asking them to test
this new feature and tag it when they're done. They may not get this
email until tomorrow or whenever, but I want to continue coding on
other features, but I don't want the testing department to get any
half-finished code while I'm working on it and committing things.
Which is why it's important for me to tell them to check out revision
100 specifically. But it might be better in this scenario for me to
create the tag, and tell the testing team the name of the tag. I'm
not sure what exactly the workflow would be, but I'm sure there are
many options. For example, I could tag it to a directory of things
that are ready to be tested; once tested successfully, the testing
team could tag it to a directory of things that have passed testing.
bar) Software version 1.0 is released. Work continues on trunk
towards version 2.0. After weeks or months of work have gone by, a
bug is found in version 1.0 and we want to quickly release a version
1.0.1. But we can't possibly do so from the current state of trunk
because it includes many new features that should only appear in 2.0.
So we go back to the revision of trunk from which 1.0 was released;
we discover in the log that this was revision 100. We can check this
out, fix the bug, and release 1.0.1. Of course, we should actually
just copy revision 100 of trunk to a 1.0 branch, check out the HEAD
of the 1.0 branch, fix the bug there, and commit it. And then tag
1.0.1 from the 1.0 branch. Of course, if we're tagging, then there
would already have been a 1.0 tag, which we could have copied to make
a 1.0 branch without needing to know any revision number. So this
turns out not to be a reason for checking out an old revision either.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 21 08:40:45 2006