David Weintraub wrote:
> On 7/28/05, Thomas Beale <thomas@deepthought.com.au> wrote:
>
>>It would be good if subversion a) supported a standard directory
>>structure like this, and b) if the tools could hide these directories
>>(at least on the client side) and instead show them as 'views' - i.e.
>>the user would be in the mainline view, the branch-xyz view, the
>>release-0.8 view and so on. I don't think it would be hard to do.
>
>
> Let's see if I can clarify this. You're really saying is that one of
> the problems with Subversion is that version common meta-data concepts
> like tags and branches are merely represented as normal, ordinary,
> every day directories and not as specialized concepts as found in
> almost every other version control system on the market. It's not that
> you insist that these directories must be named RELEASE, BRANCHES,
> TAGS, and TRUNK. It's just that Subversion should recongnize them as
> meta-data concepts and not as plain old directories.
that's correct, although I'd probably call it a missing feature in the
hope that it will someday be implemented;-) Let me be clear, lest other
posters on this list think I am being overly critical of subversion: I
view it as any other tool - it is at some point on a development path;
some things have been implemented (rather well I think), other things
have yet to come. It is discussions such as this which compare some
ideal or future concept of the tool to where it is today, which can help
the designers move forward. That's the aim (my aim at least) in the
present discussion.
> If this is what you're saying, I agree with you. I also think this is
> a problem with Subversion.
>
> Although you can successfully represent tags and branches as
> directories, the implementation is clumsy. Any command such as
> merging, taking a diff between various versions, and even making
> branches and tags is awkward.
>
> Here's an example, I create a branch called "new_features" where I am
> doing work that is taking place off the main line development. In most
> advanced CM software, creating that branch is fairly straight forward.
> In Subversion, I am making a copy:
>
> $ svn cp http://myproject/trunk http//myproject/branches/new_features
> -m "Creating branch"
>
> Okay, not too bad, but what if I did this:
>
> $svn cp http://myproject/trunk/mydirectory/mysubdir/foo_stuff
> http://myproject/branches/new_features -m "New Branch"
>
> in order to save some typing later on.
>
> There is nothing in Subversion that lets me know that the new_features
> branch is only a copy of the "foo_stuff" directory. That's something
> I have to manually track. Not only that, but what if I suddenly
> realize that the
> http://myprojects/trunk/mydirectory/mysubdir/bar_stuff also needs to
> be on this branch? In this case in Subversion, I'm in trouble.
> However, in most other CM packages, a branch type is availible to all
> files in the repository.
yes, these are the kinds of problems that emerge. Someone else said that
it is just a problem of training users, but that it not a realistic
response (even if it is literally true). As we all know in IT, people
try to do the right thing 100% of the time, and succeed say 50% - 95% of
the time. Where they fail is because the tools did not support the
required procedure, and they made a human error in trying to implement
the procedures themselves. We all do it. Adding tool support is like
adding garbage collection to a programming language - it takes away the
error-laden process of tracking memory yourself.
The representation of mainline/branch/tag/release dimensions (if I can
informally call it that) of the development space as normal directories
represents only minimal tool support for concepts which have nothing
(really) to do with directories; if they are treated as such (as in your
examples above), chaos could ensue.
Other problems that could occur due to inadvertant human misuse of these
special directories:
- writing to a tree in the tags area
- renaming or moving any of these special directores (later users might
think they had to recreate them)
Further, their presence as directories means that paths used in
makefiles and other build tools may have to include the 'trunk',
'branches' etc parts. Which means that:
a) a build file is inextricably linked to a subversion checkout environment
b) builds will break if the makefiles (maven files etc) were built for
'trunk' but are run in a 'branches/xxx' subdirectory.
This latter problems can probably be avoided by always doing checkouts
of http://some.url/some_repo/TRUNK -> some_proj_dir or
http://some.url/some_repo/BRANCHES/some_branch -> some_proj_branch_dir,
but never directly http://some.url/some_repo -> some_proj.
I have not experimented enough so far to know if this is true, but I
suspect it would be a necessary discipline to avoid getting
'trunk'/'branches' etc tangled up in the real directory structure of
projects.
>
> Merging and diffing are also excellent examples. In most CM packages,
> I could easily take a diff between my current working directory and
> any particular branch or tag by simply giving the branch or tag name.
> Since the CM package tracks the relationship between the various
> branches and tags and my current working directory for me..
>
> Things are different in Subversion. In Subversion, I have to give the
> full URL to that branch or tag since Subversion doesn't track it:
>
> $ svn diff http://myprojects/branches/new_features/mydirectory/mysubdir/bar_stuff/foo.c
>
> By the way, this may have been the reason why the user initially
> copied http://myprojects/trunk/mydirectory/mysubdir/foo_stuff to
> http://myprojects/branches/new_features to begin with even though that
> "breaks" the concept of branches. That way, the user saves some typing
> when doing diffs and merges.
>
> Does Subversion not having these meta-data concepts built right in
> make it unusable? Not at all. SCCS doesn't have tags, but I tracked
> what was in each release by creating a "release file" that listed each
> file and the SCCS version ID. SCCS, RCS, nor CVS track directory
> changes, but I did that via a makefile.
>
> However, not having these meta-data concepts built in, and easily
> accessible makes training people to use Subversion and implementing
> Subversion a bit harder. I am now forced to write hooks in order to
> keep people from accidently modifying my tags. I have to write wrapper
> scripts to make sure people are using the branches and tags directory
> the right way. The bigger my project, and the less geeky my developers
> are, the more problems I'm going to have.
These are exactly the concerns I have.
>
> Does this mean I hate Subversion, and I think it stinks, and it is
> unusable? Not at all. There is a lot to like about Subversion and I
> can see why it is so popular with many OpenSource and non OpenSource
> projects.
>
well put.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 30 13:44:22 2005