On Fri, Sep 24, 2004 at 03:32:29PM -0400, Mark Phippard wrote:
> So you say you haven't seen such agreement, then proceed to essentially
> state that it exists?
I don't think thats what I did at all.
> My whole point was exactly what you said.
> Same effect/result via different means
I think what you said was
"same effect via different means == essentially the same thing"
and I think that what I said was
"same effect via different means !necessarily= the same thing"
> I have used a handful of tools, and Subversion is the first
> one where I feel real comfortable with branching and general
> repository maintenance. I think it is because of the
> simplicity of the file-system metaphor.
I completely concur. That's swell so long as I'm doing
branching and baselining. Those are a good conceptual
> Create a promotion levels folder. Create level folders underneath it. Use
> copies to maintain what should be at each level. You could even create a
> "promote" script that hides the details.
Thats one way (and its mentioned in the article -- also
in an earlier thread on this and the dev list). I know of
about eight others. Each has their own drawbacks.
> PVCS which has a specific promotion groups feature.
> It is a nice feature, I think it would be hard to do
> it well with simple CVS-style tags.
So maybe CVS-style tags isn't the right answer. Maybe
SVN-style copies isn't either. Maybe their is something more
fundamental/elementary/basic that is little more than an
attribute or property that does this better than either
CVS or SVN currently does while still being compatible
(instead of redundant) with SVN. That would be an
interesting discussion (and the one I'm wanting to see :)
> I do not think anyone is trying to slam the door on the
> possibility of new UI. The idea needs to be explored
> better to understand what is deficient in the current
> implementation, if anything, and what the best solutions
> are going forward.
I think do do that we need to "step out" of the current
terms and mechanisms used by both SVN and CVS and refer
to the concepts by their names instead of by their
I've already seen one proposal for a revnum "alias" that
seems to build on existing instances of it (like "HEAD"
for example as simply being a special case) and would be
compatible with existing commands and syntax, and doesn't
require me to take the effort to hide something that
shouldn't have to be visible in the first place.
As for the more general issue, we already have "copies"
in SVN which go a little too far in one direction for
what is being asked for. And in the other direction we
have "Properties" which go a little too far in another
direction. Maybe there is something common between the
two that each can reuse while still supporting both, as
well as the degenerate case of a Named Property on a
file and/or revision that either exists or not, but
doesn't have a specific value associated with it (existence
via association with that particular entity is sufficient)
and doesn't have to have a URL/"copy" associated with it
Maybe whatever this is, a "Property" is a special
instance of it that can associate a value with it,
and a "copy" is a special instance of it that
can associate a file-system-view of file versions
with it. And maybe "revname" is a special instance
of a property, as is "revno", that both map to
an internal database ID that represents the basic
elementary concept - and it "manifests" itself in
different ways depending on whether it is associated
with a file, a version, a version-id, or a branch/copy.
(e.g, a traditional "baseline label" is simply a kind
of property that can apply to any (sub)set of files, but
to only one version of any given file)
Maybe by discovering this more elementary "primitive"
we can still keep consistency and simplicity intact
while still supporting multiple notions of how to use it
Brad Appleton <email@example.com> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Sep 24 22:02:57 2004