At 12:09 PM 11/15/2001 -0800, Greg Stein wrote:
>You can do that today:
>
> $ svn cp trunk tags/mytag1
> $ svn commit
Again, this does not address the situation. Let me try to explain another way.
What do people use tags for in CVS? Personally, I have used them in 4 ways.
1. To mark revisions that go into a release. You guys have been
targeting this, and I agree that the solution proposed works well.
2. To create branches. Ditto.
3. To mark files in some way that an external system can use as metadata
about the file. I've marked files that a Java build system should run an
RMI compiler on, for example. Properties will undoubtedly work fine here.
4. To do code promotion. This is the use where I'm seeing the svn cp
command being a solution, but not a very good one. Code promotion at the QA
level, which will typically be promoting entire trees, will work fine. But
at the Developer level where promotion occurs constantly on individual
files, it is a disaster.
>Since tags are just copies between directories, we don't want to enforce
>specific directory structures within the core code.
Understood. Any solution would have to be generic enough to apply anywhere
(such as the string replace I mentioned), although it would probably make
sense to include a best-practices document that showed a few setups that
were considered good ones, perhaps with supporting scripts and/or
configuration files. But I digress.
>"Tags" are copies. That is defined and closed :-)
Of course.
>How that copy is performed is up to discussion. And to some extent, it is a
>bikeshed. But all "user model" / "user interface" discussions are bikesheds
>for the most part. The hard part is figuring out the model/interface that is
>easiest and most intuitive.
I agree, and that is why I made that comment about dropping it. But somehow
the commands supported by the svn command line client "feel" more
fundamental than just a user interface issue. Perhaps it is because of the
way that the CVS command line client interface has defined all GUIs that
came afterwards, which hopefully won't be as much of a problem with
Subversion and its API for clients. Still, it feels to me like the command
line client will provide a way of thinking about the repository/working
copy relationship that will impact most clients that follow. That's the
reason I brought this whole thing up now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:48 2006