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

RE: Subversion tagging

From: L. Wayne Johnson <wayne_at_zk.com>
Date: 2007-01-23 17:57:54 CET

>>
>> >
>> >
>> >>> -----Original Message-----
>> >
>> >>> What would you do instead? Roll back your changes each time and
>> >>> try again from scratch so that when it finally passes it would be
>> >>> in a single tidy revision?
>> >>>
>> >
>> > No I would bitch and moan at people who were donating their personal
>> time to
>> > help me out...
>> >
>> > Nobody said SVN is perfect. It is what it is. You can either work with
>> it or
>> > beat your head against it. It's your choice.
>> >
>>
>> OK, while the argument is getting a bit heated and it may sound like
>> bitching, I share the irritation of having the status-tag use-case
>> dismissed
>> by some subversion disciples. The reason we are hashing out this
>> argument
>> is because we like many of the features of subversion, but we would like
>> to
>> see future enhancements to broaden its usefulness as a tool. I'm not
>> considering abandoning it. But I really hate when somebody suggests
>> "well
>> maybe this just isn't the tool for you."
>>
>> There is a significant level of demand for supporting this use-case.
>> Continuing to discuss it can hopefully build support for figuring out how
>> it
>> might be implemented in a way that complements the existing system.
>> Subversion is not a perfect tool, but it can definitely be improved.
>>
>> -Steve

I really shouldn't respond to lists at the end of the day ;-)

However, this has been discussed many times. Nothing is going to happen with
it until someone steps on to work on it. I also monitor the developer list
and it seems to me that they are all very busy. For me, the features that
they are working on our more useful than per file tags. For example merge
tracking should make it much easier to mange manage branches.

Further, subversion is very different from CVS. Both have strengths and
weaknesses. This suggests to me that processes that move from CVS to
subversion *should* change because of these differences. Much of our release
process is designed to ensure that we don't get bitten by CVS. It then
follows that the process should change significantly when moving to
subversion because it does not have some of the shortcomings of CVS and
because it has its own short comings. When moving from CVS to subversion I
believe it takes a paradigm shift to really take advantage of subversions
strengths.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 23 17:59:23 2007

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

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