You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thomas Beale <th...@deepthought.com.au> on 2005/07/29 00:25:57 UTC
early reflections on subversion methodology
I have used many CM systems, and have been thinking about whether
subversion supports the kinds of processes needed in real development,
particularly release management. I think that the basic advice of using
the trunk/tags/branches directories is ok, but does not go far enough.
We have so far defined the following in our repositories:
- TRUNK: mainline current development;
- BRANCHES: branch developments for new or alternative or test
work;
- TAGS: named baselines (no changes allowed)
- RELEASES: release branches, i.e. branches corresponding to
stable major points in the mainline (trunk) development,
whose only further allowed changes are bugfixes.
This corresponds more or less to the recommended way in Subversion of
separating mainline development; the only difference is that in our
project, upper-case directory names have been chosen to make the special
status of these directories clear in a check-out structure, and the
RELEASES directory has been added.
"Releases" are really a kind of brnch but one where the allowed types of
change is restricted to bugfixes. "Branches" are usually understood to
be rela development changes.
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.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 12, 2005, at 4:58 PM, Barry Scott wrote:
>
> How do I get a log of an item in a repo with all the tags and
> branches shown in the correct place in
> the item's time line please? I've understood that this is solvable,
> but impractical with the existing SVN API.
Yes, this is the disadvantage of having O(1) branching and tagging:
http://svn.collab.net/repos/svn/trunk/notes/schema-tradeoffs.txt
Though, in svn 2.0, I think it's fixable though extra effort.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Aug 12, 2005, at 20:44, Branko Čibej wrote:
>> The concept that you keep missing is that tags and branches have a
>> special relationship to the files they tag and branch from. Whatever
>> mechanism is used to track branches and tags needs to know that the
>> version of "foo.c" that has the tag "BARFOO" on it, and that the
>> versions of foo.c on the branch "foobar" are all related to the
>> versions of "foo.c" sitting on my main trunk.
>>
>> The truth is that Subversion simply doesn't understand this
>> relationship. This is what is making things difficult in Subversion.
>> Instead of my version control system tracking this, I now have to use
>> my poor overworked brain to do this type of stuff.
>>
> What are you talking about? Of course SVN knows about the relationship
> between the tag and it source.
>
> Not that I agree with your statement -- you're imposing your narrow
> view of the world again.
>
> -- Brane
>
I know SVN knows, but its not telling right?
How do I get a log of an item in a repo with all the tags and branches
shown in the correct place in
the item's time line please? I've understood that this is solvable, but
impractical with the existing SVN API.
Isn't the problem that when I call svn_client_log it does not return
any information about copied_to
paths that could be used to extract tag and branch info from?
And do recall that this would not change until an SVN 2.0 redesigned
schema to allow retrieval of this info
cheaply?
Far the end users point of view SVN does not understand tags and
branches because the queries and
operations that an end user wishes to do cannot be done quickly or at
all. Which is what David is
getting at.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Branko Čibej <br...@xbc.nu>.
David Weintraub wrote:
>On 8/12/05, Branko Čibej <br...@xbc.nu> wrote:
>
>
>>Thomas Beale wrote:
>>
>>
>>
>>>Branko Čibej wrote:
>>>
>>>
>>>
>>>>David Weintraub wrote:
>>>>
>>>>
>>>>
>>>>>So, it seems rather strange that Subversion doesn't understand the
>>>>>built in concepts of branches and tags. Instead, these items are
>>>>>merely emulated via pseudo-directories. After all, tags and branches
>>>>>have been implemented as part of version control systems since RCS
>>>>>back in 1985.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Subversion certainly does understand branches and tags. The important
>>>>feature of branches (and tags -- these are just branches that are
>>>>never changed after creation) is that they establish a (named)
>>>>parallel line of development that tracks its ancestry and can expose
>>>>ancestry information to procedures that need it, e.g., merge.
>>>>
>>>>From what I've been able to gather from this thread, people are
>>>>either upset or confused because directories and branches share the
>>>>same namespace, whilst most other VC systems in use today have a
>>>>separate namespace for branches.
>>>>
>>>>
>>>I don't think anyone is upset or confused. Without wishing to
>>>antagonise anyone in this discussion, it is quite clear in a formal
>>>sense that subversion doesn't directly implement the semantics of
>>>branches and tags; it just approximates them using an existing
>>>facility. To see that this is true, consider that the concept of a
>>>'tag' is not itself a 'parallel branch'; it is the name attached to a
>>>particular revision of a line of development, either the mainline, or
>>>some other branch. But it is not implemented in this way - it is
>>>implemented as a copy of some other part of the repository.
>>>
>>>
>>*Sigh*
>>
>>You're imposing your fairly narrow perception of what tags are. A tag is
>>a name for a collection of versions (a configuration in SCM-speak).
>>Those versions can all come from one branch, but that's not a
>>requirement in general. How it's implemented, and what the name looks
>>like (in SVN's case, it's an URL), is irrelevant here. And, BTW, in
>>Subversion you can create a tag that does not correspond to any
>>committed revision in the repository.
>>
>>
>
>The concept that you keep missing is that tags and branches have a
>special relationship to the files they tag and branch from. Whatever
>mechanism is used to track branches and tags needs to know that the
>version of "foo.c" that has the tag "BARFOO" on it, and that the
>versions of foo.c on the branch "foobar" are all related to the
>versions of "foo.c" sitting on my main trunk.
>
>The truth is that Subversion simply doesn't understand this
>relationship. This is what is making things difficult in Subversion.
>Instead of my version control system tracking this, I now have to use
>my poor overworked brain to do this type of stuff.
>
>
What are you talking about? Of course SVN knows about the relationship
between the tag and it source.
Not that I agree with your statement -- you're imposing your narrow view
of the world again.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: early reflections on subversion methodology
Posted by "Monks, Peter" <pe...@vignette.com>.
G'day David,
Some of what you're pointing out sounds like Subversion's current lack of merge tracking. If so, you might be pleased to know that the developers have been aware of this for some time, that it is on the roadmap [1] and that some preliminary analysis has been performed [2].
Cheers,
Peter
[1] http://subversion.tigris.org/roadmap.html
[2] http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
----------------------------------------------------------------------
Peter Monks http://www.sydneyclimbing.com/
pmonks@sydneyclimbing.com http://www.geocities.com/yosemite/4455/
----------------------------------------------------------------------
From: David Weintraub
Sent: Fri 12-Aug-05 12:22 pm
To: users@subversion.tigris.org
Cc: Thomas Beale
Subject: Re: early reflections on subversion methodology
On 8/12/05, Branko Čibej <br...@xbc.nu> wrote:
> Thomas Beale wrote:
>
> > Branko Čibej wrote:
> >
> >> David Weintraub wrote:
> >>
> >>> So, it seems rather strange that Subversion doesn't understand the
> >>> built in concepts of branches and tags. Instead, these items are
> >>> merely emulated via pseudo-directories. After all, tags and branches
> >>> have been implemented as part of version control systems since RCS
> >>> back in 1985.
> >>>
> >>>
> >> Subversion certainly does understand branches and tags. The important
> >> feature of branches (and tags -- these are just branches that are
> >> never changed after creation) is that they establish a (named)
> >> parallel line of development that tracks its ancestry and can expose
> >> ancestry information to procedures that need it, e.g., merge.
> >>
> >> From what I've been able to gather from this thread, people are
> >> either upset or confused because directories and branches share the
> >> same namespace, whilst most other VC systems in use today have a
> >> separate namespace for branches.
> >
> >
> > I don't think anyone is upset or confused. Without wishing to
> > antagonise anyone in this discussion, it is quite clear in a formal
> > sense that subversion doesn't directly implement the semantics of
> > branches and tags; it just approximates them using an existing
> > facility. To see that this is true, consider that the concept of a
> > 'tag' is not itself a 'parallel branch'; it is the name attached to a
> > particular revision of a line of development, either the mainline, or
> > some other branch. But it is not implemented in this way - it is
> > implemented as a copy of some other part of the repository.
>
> *Sigh*
>
> You're imposing your fairly narrow perception of what tags are. A tag is
> a name for a collection of versions (a configuration in SCM-speak).
> Those versions can all come from one branch, but that's not a
> requirement in general. How it's implemented, and what the name looks
> like (in SVN's case, it's an URL), is irrelevant here. And, BTW, in
> Subversion you can create a tag that does not correspond to any
> committed revision in the repository.
The concept that you keep missing is that tags and branches have a
special relationship to the files they tag and branch from. Whatever
mechanism is used to track branches and tags needs to know that the
version of "foo.c" that has the tag "BARFOO" on it, and that the
versions of foo.c on the branch "foobar" are all related to the
versions of "foo.c" sitting on my main trunk.
The truth is that Subversion simply doesn't understand this
relationship. This is what is making things difficult in Subversion.
Instead of my version control system tracking this, I now have to use
my poor overworked brain to do this type of stuff.
I don't really care about the underlying mechanism used to track
branches and tags. It can be URLs, it can be copied directories, it
can be written on the 5x3 blue-lined index cards. That's up to the
people who are far more apt at development than me to decide. I left
the development field for CM almost two decades ago, and somehow
software is still getting developed without me writing a lick of code.
> Would you feel better if we had a "svn branch" and "svn tag" command?
Actually, that would be a step in the right direction. If their was a
"svn branch" and "svn tag" command, that means that Subversion would
have a way of understanding that something is a tag or a branch and
not just a copy of a particular directory subtree to another area.
The next step would be for Subversion to use this information in a useful way.
For example, let's say I configure Subversion to use the
http://myserver/myrepos/tags directory for my tags and
http://myserver/myrepos/branches directory for my branches. In theory
a command like:
$ svn tag REL1.0 .
Seems to be the equivelent of:
$ svn cp . http://myserver/myrepos/tags/REL1.0
but if Subversion would now actually understood that this is a special
object called a "tag". I could now do something like this:
$ svn co -rREL1.0 http://myserver/myrepos/mydirectory .
And, Subversion would understand that I am really asking for the URL
http://myserver/myrepos/tags/REL1.0/mydirectory. All I need to do is
give Subversion a label, and Subversion handles the rest. Even better
would be something like this:
$ svn commit . -m "Attempting to check in a tagged Checkout"
Error: You cannot commit from a working directory based upon a tag.
Nope, not allowed to modify the tag. Now, when I, as a CM want to
build REL1.0 again, I can be absolutely sure of the sanctity of my tag
and that no one changed it without me knowing about it. Okay, their
might be times you want to modify a tag, so maybe require a "--force"
parameter and have the concept of locking tags to prevent their change
even with a "--force" parameter. Now, that would be cool.
Of course, now that Subversion understands what a tag is, I'd like to
do this too:
$ svn diff -rREL1.0 foo.c
I am now diffing my copy of foo.c with the version tagged REL1.0 and I
don't have to know the URL.
Branches would be very similar:
$ svn branch rel1_bugfix
Branch "rel1_bugfix" was created from the current URL.
Again, under the surface, this could be equivelent of
$ svn cp http://myserver/myproj/trunk http:/myserver/myproj/branches/rel1_bugfix
but Subversion would have the concept that this is a branch and has
some special properties:
$ svn co -rrel1_bugfix http://myserver/myproj/mydir mydir
I'm checking out mydir, but I am working on the rel1_bugfix branch I
created. I don't have to know where the branch is stored, since
Subversion knows it.
Of course since this is a branch and not a tag, I should be able to
check in changes:
$ svn commit -m "This is work on a branch"
created revision 655 on branch rel1_bugfix
Yup, created a new revision of the archive, but also gave me the name
of the branch to remind me that I'm not working directly on the trunk.
And, just like tags, I could take a diff between the version in my
current working directory and what is on a particular branch without
having to know the details where Subversion stored it:
$ svn diff -rrel1_bugfix foo.c
Of course, the most important thing of all in working with branches is merging:
$svn merge -rrel1_bugfix .
That would automatically merge all of the changes from my rel1_bugfix
branch to my current working directory. Since Subversion understands
the concept of a branch, it could then easily track what versions of
the code on the rel1_bugfix branch were previously merged into
whatever branch is in my current working directory. Now, I have to
manually track merges, where merging occured, what happened, etc.
The problem really isn't that Subversion can't track branches and
tags. I also implemented tags and branches as copies (literally the
Unix "cp" command) in my version control system. The problem is that
Subversion doesn't understand that these tags and branches have
special meaning to me, and should respond appropriately.
--
David Weintraub
qazwart@gmail.com
Re: early reflections on subversion methodology
Posted by David Weintraub <qa...@gmail.com>.
On 8/12/05, Branko Čibej <br...@xbc.nu> wrote:> Thomas Beale wrote:> > > Branko Čibej wrote:> >> >> David Weintraub wrote:> >>> >>> So, it seems rather strange that Subversion doesn't understand the> >>> built in concepts of branches and tags. Instead, these items are> >>> merely emulated via pseudo-directories. After all, tags and branches> >>> have been implemented as part of version control systems since RCS> >>> back in 1985.> >>>> >>>> >> Subversion certainly does understand branches and tags. The important> >> feature of branches (and tags -- these are just branches that are> >> never changed after creation) is that they establish a (named)> >> parallel line of development that tracks its ancestry and can expose> >> ancestry information to procedures that need it, e.g., merge.> >>> >> From what I've been able to gather from this thread, people are> >> either upset or confused because directories and branches share the> >> same namespace, whilst most other VC systems in use today have a> >> separate namespace for branches.> >> >> > I don't think anyone is upset or confused. Without wishing to> > antagonise anyone in this discussion, it is quite clear in a formal> > sense that subversion doesn't directly implement the semantics of> > branches and tags; it just approximates them using an existing> > facility. To see that this is true, consider that the concept of a> > 'tag' is not itself a 'parallel branch'; it is the name attached to a> > particular revision of a line of development, either the mainline, or> > some other branch. But it is not implemented in this way - it is> > implemented as a copy of some other part of the repository.> > *Sigh*> > You're imposing your fairly narrow perception of what tags are. A tag is> a name for a collection of versions (a configuration in SCM-speak).> Those versions can all come from one branch, but that's not a> requirement in general. How it's implemented, and what the name looks> like (in SVN's case, it's an URL), is irrelevant here. And, BTW, in> Subversion you can create a tag that does not correspond to any> committed revision in the repository.
The concept that you keep missing is that tags and branches have aspecial relationship to the files they tag and branch from. Whatevermechanism is used to track branches and tags needs to know that theversion of "foo.c" that has the tag "BARFOO" on it, and that theversions of foo.c on the branch "foobar" are all related to theversions of "foo.c" sitting on my main trunk.
The truth is that Subversion simply doesn't understand thisrelationship. This is what is making things difficult in Subversion.Instead of my version control system tracking this, I now have to usemy poor overworked brain to do this type of stuff.
I don't really care about the underlying mechanism used to trackbranches and tags. It can be URLs, it can be copied directories, itcan be written on the 5x3 blue-lined index cards. That's up to thepeople who are far more apt at development than me to decide. I leftthe development field for CM almost two decades ago, and somehowsoftware is still getting developed without me writing a lick of code.
> Would you feel better if we had a "svn branch" and "svn tag" command?
Actually, that would be a step in the right direction. If their was a"svn branch" and "svn tag" command, that means that Subversion wouldhave a way of understanding that something is a tag or a branch andnot just a copy of a particular directory subtree to another area.
The next step would be for Subversion to use this information in a useful way.
For example, let's say I configure Subversion to use thehttp://myserver/myrepos/tags directory for my tags andhttp://myserver/myrepos/branches directory for my branches. In theorya command like:
$ svn tag REL1.0 .
Seems to be the equivelent of:
$ svn cp . http://myserver/myrepos/tags/REL1.0
but if Subversion would now actually understood that this is a specialobject called a "tag". I could now do something like this:
$ svn co -rREL1.0 http://myserver/myrepos/mydirectory .
And, Subversion would understand that I am really asking for the URLhttp://myserver/myrepos/tags/REL1.0/mydirectory. All I need to do isgive Subversion a label, and Subversion handles the rest. Even betterwould be something like this:
$ svn commit . -m "Attempting to check in a tagged Checkout"Error: You cannot commit from a working directory based upon a tag.
Nope, not allowed to modify the tag. Now, when I, as a CM want tobuild REL1.0 again, I can be absolutely sure of the sanctity of my tagand that no one changed it without me knowing about it. Okay, theirmight be times you want to modify a tag, so maybe require a "--force"parameter and have the concept of locking tags to prevent their changeeven with a "--force" parameter. Now, that would be cool.
Of course, now that Subversion understands what a tag is, I'd like todo this too:
$ svn diff -rREL1.0 foo.c
I am now diffing my copy of foo.c with the version tagged REL1.0 and Idon't have to know the URL.
Branches would be very similar:
$ svn branch rel1_bugfixBranch "rel1_bugfix" was created from the current URL.
Again, under the surface, this could be equivelent of
$ svn cp http://myserver/myproj/trunk http:/myserver/myproj/branches/rel1_bugfix
but Subversion would have the concept that this is a branch and hassome special properties:
$ svn co -rrel1_bugfix http://myserver/myproj/mydir mydir
I'm checking out mydir, but I am working on the rel1_bugfix branch Icreated. I don't have to know where the branch is stored, sinceSubversion knows it.
Of course since this is a branch and not a tag, I should be able tocheck in changes:
$ svn commit -m "This is work on a branch"created revision 655 on branch rel1_bugfix
Yup, created a new revision of the archive, but also gave me the nameof the branch to remind me that I'm not working directly on the trunk.
And, just like tags, I could take a diff between the version in mycurrent working directory and what is on a particular branch withouthaving to know the details where Subversion stored it:
$ svn diff -rrel1_bugfix foo.c
Of course, the most important thing of all in working with branches is merging:
$svn merge -rrel1_bugfix .
That would automatically merge all of the changes from my rel1_bugfixbranch to my current working directory. Since Subversion understandsthe concept of a branch, it could then easily track what versions ofthe code on the rel1_bugfix branch were previously merged intowhatever branch is in my current working directory. Now, I have tomanually track merges, where merging occured, what happened, etc.
The problem really isn't that Subversion can't track branches andtags. I also implemented tags and branches as copies (literally theUnix "cp" command) in my version control system. The problem is thatSubversion doesn't understand that these tags and branches havespecial meaning to me, and should respond appropriately.
--David Weintraubqazwart@gmail.com
Re: early reflections on subversion methodology
Posted by Fabian Cenedese <Ce...@indel.ch>.
>>If you have a look at some of the other (better) systems, you can see that banching and tagging are almost always built-in, not just implemented in the file system.
>
>Aargh. "built in" vs. "implemented in the filesystem"? Same difference. It is simply a question of how your UI represents branches and tags.
>
>BTW, because it lets you define branch and tag namespaces in any way you want, Subversion's way is _more_ flexible than most other VC systems I've seen. I think people are just irrationally afraid of this genericity and flexibility.
>
>Would you feel better if we had a "svn branch" and "svn tag" command?
I don't necessarily need these commands but maybe a better understanding
of the existing mechanism. In cvs it's possible to move a tag. How should
I do this in svn? Can I just copy the newer files over the old ones in the tag?
Or do I need to remove the tag first and then create a new one? What
about added/deleted files? I had a case where a "moved" tag (by removing
old stuff, copying new stuff) behaved slightly different (or maybe the client).
A wc of the old tag would get newer versions of existing files after the tag
was moved. But newly added files in the tag wouldn't get updated in the
wc, no matter how I'd update. One proposal was to use "svn switch" to
the new tag. I didn't try this yet but is this the regular way or just a
work-around? Shouldn't "svn update" always get the state of the tag, no
matter how this was created/moved/copied etc?
Thanks
bye Fabi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Frank Gruman <fg...@verizon.net>.
I think it has been mentioned on this thread before, but much of this
discussion seems like it could be rectified by a series of properly
configured hook scripts and an admin GUI (hook scripts configured in the
GUI would be wonderful). If someone took something like SVNManager
(http://svnmanager.sourceforge.net) and added a bit more functionality
(rules and such), then much of this conversation would be moot. That
system could have rules stating what your repository structure should
be, which areas to commit or not to commit, run repository reports that
could scan your svn logs, and even (if you're really good) tell you when
the coffee is done.
The only reason I mention SVNManager is that it is what I am using. It
is a UI that allows me to not have to remember all of the svnadmin
commands and I can maintain my repository from just about anywhere. It
allows me to create a repository and configure users/groups. The rest
of the functionality would sure be nice some day, but I am not a
perl/php/python programmer, so I will have to wait for some one else to
build it.
I am not a SCM guru. I will not claim to be. But the discussion here
goes back and forth between the way a 'better' (VERY subjective) SCM
would do things and the way Subversion does them. I think it
appropriate when Brane stated that Subversion does most of what you want
and more. The system is TO flexible for some people to see. It's like
not being able to see the trees because the forest is getting in our
way. To many choices - to many decisions to make - no pre-defined,
fixed structure to adhere to. I think another thread a while back had
mentioned the creation of a second document to supplement the good
book. Something about a 'best practices' or 'alternative practices'
where there are samples of different uses of the system. The discussion
focused around the idea that the /trunk,/branches,/tags layout and
examples did not necessarily make for easy understanding for people who
didn't develop in this way.
just another 2 cents from me...
Regards,
Frank
Branko Čibej wrote:
> A.T.Hofkamp wrote:
>
>> Hello all,
>>
>> Branko Čibej wrote:
>>
>>> BTW, because it lets you define branch and tag namespaces in any way
>>> you want, Subversion's way is _more_ flexible than most other VC
>>> systems I've seen. I think people are just irrationally afraid of
>>> this genericity and flexibility.
>>
>>
>>
>> I don't think 'irritionally afraid' would be the correct term, I'd
>> call it 'getting lost in the ocean of possibilities'.
>
>
> Well, O.K. :-)
>
> [...]
>
>> Having a set of standard procedures for the standard things would go
>> a long way. A kind of user guide for using a version management system.
>> In the svn-book, and many other books about SCM, the command to
>> create or merge a branch is given, the command to create a tag is
>> given, but the procedure as a whole is not (the 1 line command is
>> kind of the end result of following a procedure).
>> For example, to create a branch (and I have never done this in real
>> life with svn, so don't assume that the procedure below makes any
>> sense):
>>
>> (assuming project/{trunk,branches,tags} repository layout):
>> 1. come up with a nice name for your new branch (assuming 'newname')
>> 2. check that the name is not in use in /project/branches
>> 3. copy the trunk to the branch
>> svn copy ..../project/trunk .../project/branches/newname
>> 4. make a tag to merge back to the trunk against later
>> svn copy ..../project/branches/newname \
>> .../project/tags/newname-branch-<repo-number>
>>
>> While this is not earth moving in any way, it does make these
>> procedures (and use of svn/SCM in general) more tangible for
>> new/inexperienced users.
>> (ie such procedures create a nice starting point, an island in the
>> ocean imho).
>
>
> (BTW, the SVN book does recommend a certain repository layout.)
>
> So, basically what you'd like is a book that would be called called
> "Configuration Management with Subversion", possibly as Volume 2 of
> "Version Control with Subversion"; is that a close guess?
>
> -- Brane
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Branko Čibej <br...@xbc.nu>.
A.T.Hofkamp wrote:
> Hello all,
>
> Branko Čibej wrote:
>
>> BTW, because it lets you define branch and tag namespaces in any way
>> you want, Subversion's way is _more_ flexible than most other VC
>> systems I've seen. I think people are just irrationally afraid of
>> this genericity and flexibility.
>
>
> I don't think 'irritionally afraid' would be the correct term, I'd
> call it 'getting lost in the ocean of possibilities'.
Well, O.K. :-)
[...]
> Having a set of standard procedures for the standard things would go a
> long way. A kind of user guide for using a version management system.
> In the svn-book, and many other books about SCM, the command to create
> or merge a branch is given, the command to create a tag is given, but
> the procedure as a whole is not (the 1 line command is kind of the end
> result of following a procedure).
> For example, to create a branch (and I have never done this in real
> life with svn, so don't assume that the procedure below makes any sense):
>
> (assuming project/{trunk,branches,tags} repository layout):
> 1. come up with a nice name for your new branch (assuming 'newname')
> 2. check that the name is not in use in /project/branches
> 3. copy the trunk to the branch
> svn copy ..../project/trunk .../project/branches/newname
> 4. make a tag to merge back to the trunk against later
> svn copy ..../project/branches/newname \
> .../project/tags/newname-branch-<repo-number>
>
> While this is not earth moving in any way, it does make these
> procedures (and use of svn/SCM in general) more tangible for
> new/inexperienced users.
> (ie such procedures create a nice starting point, an island in the
> ocean imho).
(BTW, the SVN book does recommend a certain repository layout.)
So, basically what you'd like is a book that would be called called
"Configuration Management with Subversion", possibly as Volume 2 of
"Version Control with Subversion"; is that a close guess?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by "A.T.Hofkamp" <a....@tue.nl>.
Hello all,
Branko Čibej wrote:
> BTW, because it lets you define branch and tag namespaces in any way you
> want, Subversion's way is _more_ flexible than most other VC systems
> I've seen. I think people are just irrationally afraid of this
> genericity and flexibility.
I don't think 'irritionally afraid' would be the correct term, I'd call it
'getting lost in the ocean of possibilities'.
I think that many people (including me), cannot oversee what the system is
actually doing/capable of, exactly due to this genericity and flexibility.
Taking myself as an example, as naive user, I just want to 'do version
management'. To questions like 'how should I layout the repository', 'how do I
manage branches/tags', and many other questions, the answer is (to a large
degree) 'anything you like'.
That isn't exactly helping in solving my problem.
In other words, I feel sometimes a bit 'lost' with these matters.
[ not that I critize any one here (especially the developers!). You are all
doing a wonderful job of making software, the software is just too powerful
for me to (fully) understand.
]
> Would you feel better if we had a "svn branch" and "svn tag" command?
in one way, yes. It gives me a hard border/baseline to think out the solution
to my problem against.
in another way, no. No doubt, I will want to get around the border tomorrow
and do things just a tad different.
I very much doubt that this problem should be solved in software, in
particular at the server side.
Having a set of standard procedures for the standard things would go a long
way. A kind of user guide for using a version management system.
In the svn-book, and many other books about SCM, the command to create or
merge a branch is given, the command to create a tag is given, but the
procedure as a whole is not (the 1 line command is kind of the end result of
following a procedure).
For example, to create a branch (and I have never done this in real life with
svn, so don't assume that the procedure below makes any sense):
(assuming project/{trunk,branches,tags} repository layout):
1. come up with a nice name for your new branch (assuming 'newname')
2. check that the name is not in use in /project/branches
3. copy the trunk to the branch
svn copy ..../project/trunk .../project/branches/newname
4. make a tag to merge back to the trunk against later
svn copy ..../project/branches/newname \
.../project/tags/newname-branch-<repo-number>
While this is not earth moving in any way, it does make these procedures (and
use of svn/SCM in general) more tangible for new/inexperienced users.
(ie such procedures create a nice starting point, an island in the ocean imho).
Albert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Branko Čibej <br...@xbc.nu>.
Thomas Beale wrote:
> Branko Čibej wrote:
>
>> David Weintraub wrote:
>>
>>> So, it seems rather strange that Subversion doesn't understand the
>>> built in concepts of branches and tags. Instead, these items are
>>> merely emulated via pseudo-directories. After all, tags and branches
>>> have been implemented as part of version control systems since RCS
>>> back in 1985.
>>>
>>>
>> Subversion certainly does understand branches and tags. The important
>> feature of branches (and tags -- these are just branches that are
>> never changed after creation) is that they establish a (named)
>> parallel line of development that tracks its ancestry and can expose
>> ancestry information to procedures that need it, e.g., merge.
>>
>> From what I've been able to gather from this thread, people are
>> either upset or confused because directories and branches share the
>> same namespace, whilst most other VC systems in use today have a
>> separate namespace for branches.
>
>
> I don't think anyone is upset or confused. Without wishing to
> antagonise anyone in this discussion, it is quite clear in a formal
> sense that subversion doesn't directly implement the semantics of
> branches and tags; it just approximates them using an existing
> facility. To see that this is true, consider that the concept of a
> 'tag' is not itself a 'parallel branch'; it is the name attached to a
> particular revision of a line of development, either the mainline, or
> some other branch. But it is not implemented in this way - it is
> implemented as a copy of some other part of the repository.
*Sigh*
You're imposing your fairly narrow perception of what tags are. A tag is
a name for a collection of versions (a configuration in SCM-speak).
Those versions can all come from one branch, but that's not a
requirement in general. How it's implemented, and what the name looks
like (in SVN's case, it's an URL), is irrelevant here. And, BTW, in
Subversion you can create a tag that does not correspond to any
committed revision in the repository.
>> But this is in fact just a UI detail. It does not meant that SVN
>> doesn't "support" branches, and it certainly doesn't make SVN's
>> branches second-class objects.
>
>
>
> I disagree; it's not just a UI detail. Subversion's branches are not
> first-class objects; they are simply copies of other parts of the
> filesystem; there is nothing except human process to make sure that
> they are not accidentally abused.
Oh foo. Of course it's a UI detail. Or do you suppose that branches, in
ClearCase, are not conceptually isomorphic to copies (albeit in a
different namespace)?
> There's also a huge benefit in having a single namespace -- namely,
> WebDAV/DeltaV interoperability. We'd have had a lot more trouble
> getting that if we had more than one namespace.
>
> I disagree here as well. Having TRUNK/BRANCHES/TAGS in the directory
> tree is a real nuisance for build scripts.
But your build scripts don't have to know about these things. What's the
difference between saying "Build from this tag" or "Build from this
URL"? None at all.
> It would be easy to make these disappear on the server side, while
> retaining the dav_svn view of things. It's just a matter of how the
> dav_svn apache module is implemented.
Read the WebDAV spec. This has nothing to do with how mod_dav_svn is
implemented.
> If you have a look at some of the other (better) systems, you can see
> that banching and tagging are almost always built-in, not just
> implemented in the file system.
Aargh. "built in" vs. "implemented in the filesystem"? Same difference.
It is simply a question of how your UI represents branches and tags.
BTW, because it lets you define branch and tag namespaces in any way you
want, Subversion's way is _more_ flexible than most other VC systems
I've seen. I think people are just irrationally afraid of this
genericity and flexibility.
Would you feel better if we had a "svn branch" and "svn tag" command?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <Th...@OceanInformatics.biz>.
Branko Čibej wrote:
> David Weintraub wrote:
>
>> So, it seems rather strange that Subversion doesn't understand the
>> built in concepts of branches and tags. Instead, these items are
>> merely emulated via pseudo-directories. After all, tags and branches
>> have been implemented as part of version control systems since RCS
>> back in 1985.
>>
>>
> Subversion certainly does understand branches and tags. The important
> feature of branches (and tags -- these are just branches that are
> never changed after creation) is that they establish a (named)
> parallel line of development that tracks its ancestry and can expose
> ancestry information to procedures that need it, e.g., merge.
>
> From what I've been able to gather from this thread, people are either
> upset or confused because directories and branches share the same
> namespace, whilst most other VC systems in use today have a separate
> namespace for branches.
I don't think anyone is upset or confused. Without wishing to antagonise
anyone in this discussion, it is quite clear in a formal sense that
subversion doesn't directly implement the semantics of branches and
tags; it just approximates them using an existing facility. To see that
this is true, consider that the concept of a 'tag' is not itself a
'parallel branch'; it is the name attached to a particular revision of a
line of development, either the mainline, or some other branch. But it
is not implemented in this way - it is implemented as a copy of some
other part of the repository.
>
> But this is in fact just a UI detail. It does not meant that SVN
> doesn't "support" branches, and it certainly doesn't make SVN's
> branches second-class objects.
I disagree; it's not just a UI detail. Subversion's branches are not
first-class objects; they are simply copies of other parts of the
filesystem; there is nothing except human process to make sure that they
are not accidentally abused.
> There's also a huge benefit in having a single namespace -- namely,
> WebDAV/DeltaV interoperability. We'd have had a lot more trouble
> getting that if we had more than one namespace.
I disagree here as well. Having TRUNK/BRANCHES/TAGS in the directory
tree is a real nuisance for build scripts. It would be easy to make
these disappear on the server side, while retaining the dav_svn view of
things. It's just a matter of how the dav_svn apache module is implemented.
If you have a look at some of the other (better) systems, you can see
that banching and tagging are almost always built-in, not just
implemented in the file system.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Branko Čibej <br...@xbc.nu>.
David Weintraub wrote:
>So, it seems rather strange that Subversion doesn't understand the
>built in concepts of branches and tags. Instead, these items are
>merely emulated via pseudo-directories. After all, tags and branches
>have been implemented as part of version control systems since RCS
>back in 1985.
>
>
Subversion certainly does understand branches and tags. The important
feature of branches (and tags -- these are just branches that are never
changed after creation) is that they establish a (named) parallel line
of development that tracks its ancestry and can expose ancestry
information to procedures that need it, e.g., merge.
From what I've been able to gather from this thread, people are either
upset or confused because directories and branches share the same
namespace, whilst most other VC systems in use today have a separate
namespace for branches.
But this is in fact just a UI detail. It does not meant that SVN doesn't
"support" branches, and it certainly doesn't make SVN's branches
second-class objects. There's also a huge benefit in having a single
namespace -- namely, WebDAV/DeltaV interoperability. We'd have had a lot
more trouble getting that if we had more than one namespace.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <Th...@OceanInformatics.biz>.
David Weintraub wrote:
>
>In each one, we were able to build a complete development system by
>simply writing our own wrappers around an existing system. Each
>succeeding generation brought in more features that were originally
>written in our wrapper scripts because these features became to be
>understood as part and parcel of a basic version control system.
>
>So what is a basic VCS feature?
>
>
I would argue that the critical features in a version control
environment include:
- change management not just of content changes, but moves, deletes and
renames
- ability to branch the entire repository
- ability to tag, or create baseline markers
- ability to roll-back to any previous commit point
- ability to treat any set of individual changes committed at once as a
change-set
My critical features for a CM system would be:
- connecting change-sets to Change Requests (or engineering change
orders, or program amendment requests or whatever your shop calls them)
- supporting release management, i.e. some support for multiple
concurrent release branches, where each previously released branch can
only be changed by bug fixes. This is really just branch management with
a bit of workflow and documentation added.
The rest of this post I agree with.
>Maybe we can draw a parallel example with the automobile industry. In
>cars, features are divided into three groups: Basic features (you
>expect your car to have brakes), comfort features (sunroof, high end
>materials, heated seats), high end features (GPS system, high end
>sound system, multizone ac/heating system).
>
>
...
>Can you version control without true tags and branches? Well, I use to
>do version control on a system that didn't have a concept of of a
>source archive (just as a Russian friend of mine use to drive a car
>that didn't have the concept of "brakes"). All I had to do was spend
>lots of time attempting to implement the non-existent concept and then
>fixing the errors and training users to understand my front end.
>
>Today, we now spend time implementing on top of Subversion the concept
>of tags and branches. We parse the output of "svn log", we write
>hooks, we use directories, we train users in the "correct way" to do
>something, and we spend time fixing mistakes.
>
>
this is the way I see it too. It's not a criticism of svn in the sense
that I think it is 'broken'; just that it has chosen a kind of
pseudo-implementation of these important features. It's surprising the
developers bothered putting anything under the rubric 'tags' and
'branches'; in their place I would have either done nothing (svn would
still be a versioned file system) or built the semantics right in,
rather than just approximating them with existing file clone facilities.
But as I stated earlier, such features could easily belong to another
layer on the server side.
>There's a lot of great stuff in Subversion. The atomic commits, the
>flexibility of the client, the ease of installation, the open source
>nature which means I don't have to track licenses, the ability to work
>through standard Internet protocols all make Subversion an excellent
>tool. I understand Subversion is still a young tool, and new features
>are being added all the time. I also have a small list I'd like to
>see:
>
>* Tags and branches implemented as true meta-data types
>* Merging that is clean and simple (needs true branching first in order to work)
>* The ability to query files by various properties.
>* Remove old file versions. I would like to version a set of 700mb CD
>images, but that would quickly over whelm my archive storage and my
>SysAdmin's ability to do backups. It would be possible if I could
>remove the old versions of files that we no longer need, but that's
>only possible via a dump and load.
>* Remove the entire history of a file. Sometimes, a file that
>shouldn't be in the archive is accidentally added to the archive. If
>this file contains proprietary information, it must be scrubbed from
>the archive. Unfortunately, you can't remove it in Subversion.
>
>
I agree with all these (the last was possible in BitKeeper, using a
non-user friendly command, ideal for making deletion just hard enough
that only experts could do it).
>* A new type of property that is a cross between a file property and a
>revision property. I'd like to attach a property on a revision of a
>particular file. For example, to mark if that file had been
>peer-reviewed or tested by QA or whatever else I might want.
>
>
I would expect such activities to make sense across a whole baseline,
not just a single file, so I would want to be able to add such meta-data
to a named release or tag, not a file.
- thomas beale
--
___________________________________________________________________________________
CTO Ocean Informatics (http://www.OceanInformatics.biz)
Research Fellow, University College London (http://www.chime.ucl.ac.uk)
Chair Architectural Review Board, openEHR (http://www.openEHR.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by David Weintraub <qa...@gmail.com>.
On 8/1/05, Branko Čibej <br...@xbc.nu> wrote:> That said, I'll reiterate that Subversion is a version control tool, not> a CM tool. It has (most) of the features you need to build a CM system,> but it is not a CM system by itself.
The question becomes what features are the heart and sole of a versioncontrol system, and when does a particular feature make a VCS into aCM system.
Let's take a look at SCCS again. I used SCCS for years even though ithad no ability to create tags or do more than a single one deep branchstructure. TCCS, PCMS, BitKeeper, and Sablime were all strong CMsystems built on top of SCCS. So, it seems that SCCS had more thanenough features to handle basic version control.
However, SCCS was quickly replaced by RCS because RCS had the conceptof tags (names in RCS parlance) and had the ability to offer infinitedepth branching. CVS started off as a bunch of Perl "CM" shell scriptsthat wrapped around the basic RCS commands but quickly grew into aversion control tool in its own right because it plugged in many ofmissing version control features not found in basic RCS itself.
Then again, when I first started programming (back when I wasconsidered a User Interface guru because I knew the ins and outs ofthe curses library), we simply did version control by saving copies ofour files with suffixes marking the "version" number of our files. Ifwe needed to branch, we would simply copy the whole structure toanother directory. I wrote a bunch of shell scripts to do stuff asmerging, checking in and out files, and branching. Who needs any ofthe "CM" features found in SCCS when you have the Unix "diff", "cp",and "mv" commands?
So let's look at the history of Version Control Systems:
* Pre-SCCS: Shell scripts around "cp", "diff", and "mv"* SCCS: Added the idea of archives, built in logging, branching, and diffing* RCS: Expanded branching and built in the concept of tags* CVS: Concept of a single source archive (instead of dozens of sourcearchive directories), workspaces, and establishing developmentworkflow (checkout, work, update, commit).
In each one, we were able to build a complete development system bysimply writing our own wrappers around an existing system. Eachsucceeding generation brought in more features that were originallywritten in our wrapper scripts because these features became to beunderstood as part and parcel of a basic version control system.
So what is a basic VCS feature?
Maybe we can draw a parallel example with the automobile industry. Incars, features are divided into three groups: Basic features (youexpect your car to have brakes), comfort features (sunroof, high endmaterials, heated seats), high end features (GPS system, high endsound system, multizone ac/heating system).
Over the years, features once associated with the high end, move downto the comfort level and into the basic level. For example, when I wasa kid, only Cadillacs had electric windows. Today, even the most basiceconomy car comes with them.
The same thing happens with VCS features. What once was considered ahigh-end, but unnecessary feature has turned into an expected minimumrequirement. Subversion has upped the ante with its atomic commits andthe use of being able to work with well established protocols thatinclude built in security. In a few years, almost all version controlsystems will sport these must-have features.
So, it seems rather strange that Subversion doesn't understand thebuilt in concepts of branches and tags. Instead, these items aremerely emulated via pseudo-directories. After all, tags and brancheshave been implemented as part of version control systems since RCSback in 1985.
Can you version control without true tags and branches? Well, I use todo version control on a system that didn't have a concept of of asource archive (just as a Russian friend of mine use to drive a carthat didn't have the concept of "brakes"). All I had to do was spendlots of time attempting to implement the non-existent concept and thenfixing the errors and training users to understand my front end.
Today, we now spend time implementing on top of Subversion the conceptof tags and branches. We parse the output of "svn log", we writehooks, we use directories, we train users in the "correct way" to dosomething, and we spend time fixing mistakes.
There's a lot of great stuff in Subversion. The atomic commits, theflexibility of the client, the ease of installation, the open sourcenature which means I don't have to track licenses, the ability to workthrough standard Internet protocols all make Subversion an excellenttool. I understand Subversion is still a young tool, and new featuresare being added all the time. I also have a small list I'd like tosee:
* Tags and branches implemented as true meta-data types* Merging that is clean and simple (needs true branching first in order to work)* The ability to query files by various properties. * Remove old file versions. I would like to version a set of 700mb CDimages, but that would quickly over whelm my archive storage and mySysAdmin's ability to do backups. It would be possible if I couldremove the old versions of files that we no longer need, but that'sonly possible via a dump and load.* Remove the entire history of a file. Sometimes, a file thatshouldn't be in the archive is accidentally added to the archive. Ifthis file contains proprietary information, it must be scrubbed fromthe archive. Unfortunately, you can't remove it in Subversion.* A new type of property that is a cross between a file property and arevision property. I'd like to attach a property on a revision of aparticular file. For example, to mark if that file had beenpeer-reviewed or tested by QA or whatever else I might want.
Some of these features I consider a necessity. Others are merely niceto have. However, I don't believe any of these features are considered"CM" features, but merely tools used in order to build a CM system. ACM system is more than just archiving tools. CM is the method used inthe development of the product. You build your CM system upon theversion control system and other various tools you have.
--David Weintraubqazwart@gmail.com
Re: early reflections on subversion methodology
Posted by Branko Čibej <br...@xbc.nu>.
Thomas Beale wrote:
> You are really missing the point here. What I am talking about is not
> how "our" team works, it's more or less how CM is done. I am not of
> course saying that there are not variations or no flexibility, but in
> a mathematical sense, the relationship of mainline, alternate
> branches, release branches, and tags is relatively well-defined. Not
> everyone implements it the same way, but the intended logic is usually
> the same. There are many publications in the CM area which describe
> these concepts; all large organisations I have worked in have had the
> same requirements for this aspect of CM.
I agree in concept.
That said, I'll reiterate that Subversion is a version control tool, not
a CM tool. It has (most) of the features you need to build a CM system,
but it is not a CM system by itself.
Now, before somebody jumps up and starts telling us that "this is
missing from Subversion", I'll give you a hint: the above statement
holds fo 90% of the commercial "CM" tools.
For example, you don't get configuration management by buying ClearCase;
even its UCM features don't make it a "CM" tool. But you can certainly
build a CM process with ClearCase, just as you can with Subversion.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
Brass Tilde wrote:
>>Apparently I have not explained myself sufficiently clearly...what I am
>>suggesting is that knowledge of the directories
>>trunk/tags/branches/release be built into the tools at the client end.
>
>
> And other people have said that would be a less than good thing, because not every development team does it that way. Even those
> who *do* do it that way may not do it in the same way. For instance, while we use the trunk/, tags/ and branches/ directory schema,
> ours are at the root of the repository instead of within each project. In addition, our releases/ branch appears under tags/,
> because our releases are static, never again to be worked on. Many people don't use anything resembling releases/ at all.
>
many don't perhaps, but many do. For a brief explanation of how many
organisations manage releases see chapter 5 of
http://svn.openehr.org/specification/TRUNK/publishing/CM/CM_plan.pdf,
which simply describes in minimal detail the concept of a release as a
branch whose further development is limited to bugfixes. Named
"releases" are tags of those release branches (admittedly the
terminology in CM is a bit confusing sometimes).
>
>>This would be done in such a way that they would no longer appear in the
>>'normal' directory hierarchy but instead would (for example) display the
>>contents of those directories as views, or in some other way. Then other
>>rules could be attached to those views, such as the rule that the tags
>>view is readonly after creation and so on. Doing this just enables the
>>machine to implement the discipline instead of humans having to do it,
>>which is the current case.
>
>
> As others have said, this would make the program directly responsible for enforcing the way *your* team works. As it stands right
> now, Subversion will already support your way of working, it just takes a little more work on your part. It also supports *my* way
> of working, and a host of others.
You are really missing the point here. What I am talking about is not
how "our" team works, it's more or less how CM is done. I am not of
course saying that there are not variations or no flexibility, but in a
mathematical sense, the relationship of mainline, alternate branches,
release branches, and tags is relatively well-defined. Not everyone
implements it the same way, but the intended logic is usually the same.
There are many publications in the CM area which describe these
concepts; all large organisations I have worked in have had the same
requirements for this aspect of CM.
Having this logic implemented in a flexible form would mean that you can
ignore it entirely and do your own thing. If used, it could be
configured according to particularities of the project (which is what
most commerccial CM systems allow). But many users I believe would like
accepted CM branching and tagging concepts supported outside of the
directory system, or at least in a way such that these meta-concepts did
not _appear_ in the directory system (even if they were, on the server
side).
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Brass Tilde <br...@insightbb.com>.
> Apparently I have not explained myself sufficiently clearly...what I am
> suggesting is that knowledge of the directories
> trunk/tags/branches/release be built into the tools at the client end.
And other people have said that would be a less than good thing, because not every development team does it that way. Even those
who *do* do it that way may not do it in the same way. For instance, while we use the trunk/, tags/ and branches/ directory schema,
ours are at the root of the repository instead of within each project. In addition, our releases/ branch appears under tags/,
because our releases are static, never again to be worked on. Many people don't use anything resembling releases/ at all.
> This would be done in such a way that they would no longer appear in the
> 'normal' directory hierarchy but instead would (for example) display the
> contents of those directories as views, or in some other way. Then other
> rules could be attached to those views, such as the rule that the tags
> view is readonly after creation and so on. Doing this just enables the
> machine to implement the discipline instead of humans having to do it,
> which is the current case.
As others have said, this would make the program directly responsible for enforcing the way *your* team works. As it stands right
now, Subversion will already support your way of working, it just takes a little more work on your part. It also supports *my* way
of working, and a host of others.
> But if it were there, I think most users would choose to use it.
I've seen no proof of that. There is a relatively easy way to prove it though, simply build a client that does the things you want,
and see if "most users [...] choose to use it."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Niels Skou Olsen <ns...@dk.manbw.com>.
Thomas Beale <th...@deepthought.com.au> writes:
> Robert P. J. Day wrote:
>> On Fri, 29 Jul 2005, Thomas Beale wrote:
[...]
>> i understand what you're saying but how would you suggest this be
>> done? not in terms of actual implementation, just in the abstract
>> sense?
>> first, i'm hoping that, by typing "view", you're not suggesting that
>> this would require a GUI of some sort.
>
> not literally no. What I meant was: imagine you did a checkout of a
> repostory; imagine then that you had to do a set_view command to choose
> trunk or some named branch of development, and that thereafter you were in
> the normal directory structure, but corresponding to the chosen version of
> development.
Seems to be exactly what 'svn switch' does: transform your working copy (or
view, if you want) to the desired named development line. The name of the
development line is a repository path. Easy, simple, effective.. ;-)
[...]
/Niels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
Robert P. J. Day wrote:
> On Fri, 29 Jul 2005, Thomas Beale wrote:
>
>
>>Apparently I have not explained myself sufficiently clearly...what I
>>am suggesting is that knowledge of the directories
>>trunk/tags/branches/release be built into the tools at the client
>>end. This would be done in such a way that they would no longer
>>appear in the 'normal' directory hierarchy but instead would (for
>>example) display the contents of those directories as views, or in
>>some other way.
>
>
> i understand what you're saying but how would you suggest this be
> done? not in terms of actual implementation, just in the abstract
> sense?
>
> first, i'm hoping that, by typing "view", you're not suggesting that
> this would require a GUI of some sort.
not literally no. What I meant was: imagine you did a checkout of a
repostory; imagine then that you had to do a set_view command to choose
trunk or some named branch of development, and that thereafter you were
in the normal directory structure, but corresponding to the chosen
version of development.
>
> having the trunk/tags/branches/etc. appear as normal directories might
> seem tacky to you, but it's a *very* simple way to support this. i
> get the feeling that, if you tried to make this more transparent, it
> would just get way more complicated for little gain.
>
> rday
Well it's not a case of being tacky, it's just that the directory system
is being used to simulate something which has nothing to do with
directories. It's not that it doesn't work at all, but it will cause
errors, and inconsistencies (e.g. in paths in build scripts).
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by "Robert P. J. Day" <rp...@mindspring.com>.
On Fri, 29 Jul 2005, Thomas Beale wrote:
> Apparently I have not explained myself sufficiently clearly...what I
> am suggesting is that knowledge of the directories
> trunk/tags/branches/release be built into the tools at the client
> end. This would be done in such a way that they would no longer
> appear in the 'normal' directory hierarchy but instead would (for
> example) display the contents of those directories as views, or in
> some other way.
i understand what you're saying but how would you suggest this be
done? not in terms of actual implementation, just in the abstract
sense?
first, i'm hoping that, by typing "view", you're not suggesting that
this would require a GUI of some sort.
having the trunk/tags/branches/etc. appear as normal directories might
seem tacky to you, but it's a *very* simple way to support this. i
get the feeling that, if you tried to make this more transparent, it
would just get way more complicated for little gain.
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Gábor Szabó <sz...@gmail.com>.
On 7/30/05, Thomas Beale <th...@deepthought.com.au> wrote:
> Robert P. J. Day wrote:
> > On Sat, 30 Jul 2005, Thomas Beale wrote:
> >
> > as more than one person has pointed out, there's nothing magical about
> > directories named "Branches" or "Tags" or "Releases" -- it's all in
> > the way you treat them, that's all.
>
> But there should. The formal semantics of these directories are not
> those of a normal project directory; they are there to separate out
> different branches of development, and also to implement tags. But the
> semantics of these things are not the semantics of directories.
>
> >
> > and while any client tool would most likely want to have some
> > pre-defined set of perspectives like main, branches, tags and so on,
>
> 'perspectives' is exactly the word I was looking for.
>
> > the directory structure effortlessly let's you define certain views of
> > the repository as, say, "Rob's Wild and Crazy Ideas" and stuff like
> > that.
> >
> > will your hypothetical client tool be able to handle that kind of
> > flexibility?
> >
> > rday
>
> "Rob's wild and crazy ideas" would probably be the name of a branch in
> the 'branches' perspective, but there is no reason why people couldn't
> invent their own perspective names as well.
>
> - thomas beale
While with some restrictions you could already create such a front-end
to Subversion.
I think this was actually already suggested when someone told you to
write your own
client. My suggestion would be similar with the idea to show how such thing
would work.
You can write a script in your favorite programming language that will
wrap the svn client (or using one of its bindings) so you have
command like this
mysvn co http://url_to_repo workspace
will actually check out http://url_to_repo/TRUNK to the
workspace directory
mysvn co http://url_to_repo --flow NAME workspace
will check out http://url_to_repo/BRANCHES/NAME
or http://url_to_repo/TAGS/NAME
or http://url_to_repo/RELEASES/NAME
to the workspace directory
We assume the same NAME cannot exist in two places and we enforce this by
our command line tool.
mysvn switch NAME
would switch to the named BRANCH/TAGS/RELEASE
mysvn --branch NAME
would be translated to
svn cp http://url_to_repo/TRUNK http://url_to_repo/BRANCHES/NAME
mysvn --tag NAME
mysvn --release NAME
mysvn --mergefrom NAME
would be translated to
svn merge http://url_to_repo/BRANCHES/NAME
or
svn merge http://url_to_repo/TAGS/NAME
or
svn merge http://url_to_repo/RELEASES/NAME
Gabor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Scott Palmer <sc...@2connected.org>.
On 2-Aug-05, at 5:55 AM, Thomas Beale wrote:
> Scott Palmer wrote:
>
>> On 1-Aug-05, at 5:41 AM, Thomas Beale wrote:
>>
>>> I haven't had the time to think an architectural solution
>>> through, but all this sounds very reasonable. One thing I am
>>> fairly sure of: there would not be any "tags" directory; I would
>>> simply record the tag against the revision number being tagged.
>>> Of course this mitigates against using multiple project trees in
>>> one repository, which I initially thought sounded good, but in
>>> the end I think is unusable; it has to be one project per
>>> repository. Doing otherwise renders the versioning across the
>>> board completely meaningless, and means that svn really is just
>>> a versioned file-system (and I'm not knocking that!).
>>
>> I don't follow. I am currently using subversion with multiple
>> projects per repository and I am recording milestones by revision
>> number, not 'tags'. It works fine.
>
> Are you saying that you don't use tags at all?
I have not yet used the Subversion cheap-copy-as-tag feature.
> What if you want to do a checkout of a named revision, e.g.
> "release-0.9"?
At the moment that would be a bit more tedious than it needs to be,
but we have recorded the repo paths and revisions that make up each
release, we can go back and make cheap-copy tags if we want. But I
just haven't automated our build process to create the tags in the
repository when we do a release build.
> And normally, one would want tags to apply on a per-project basis;
> e.g. "release-0.9" of one project might co-exist with "alpha-
> release" and "dotnet-test" in other projects.
We don't put trunk,branches,tags in the root of our repository. We
put those under project folders. You will note that from a URL
standpoint this gives you the same structure as if you had one
repository per project with the trunk,branches,tags folders in the
root of each repository. E.g. "svn://server/project/trunk" <-- can
you tell if 'project' is a folder on the server or within the
repository? (Hint: I'm using the --root option to svnserve.)
> So you can't sensibly tag the entire repository with a particular
> tag name; you have to copy prject subtrees into named tag
> directories, which I would say is very prone to human error
By prone to human error, what do you mean? Copying project1/trunk
to project1/tags/release-0.9 seems pretty simple to me. In your case
'project1' is the directory OF the repository, in my case it is a
directory IN the respository.
> From what you say, you must be managing a separate file of tags and
> revisions.
Yes, that is what I'm doing at the moment.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <Th...@OceanInformatics.biz>.
Scott Palmer wrote:
>
> On 1-Aug-05, at 5:41 AM, Thomas Beale wrote:
>
>> I haven't had the time to think an architectural solution through,
>> but all this sounds very reasonable. One thing I am fairly sure of:
>> there would not be any "tags" directory; I would simply record the
>> tag against the revision number being tagged. Of course this
>> mitigates against using multiple project trees in one repository,
>> which I initially thought sounded good, but in the end I think is
>> unusable; it has to be one project per repository. Doing otherwise
>> renders the versioning across the board completely meaningless, and
>> means that svn really is just a versioned file-system (and I'm not
>> knocking that!).
>
>
>
> I don't follow. I am currently using subversion with multiple
> projects per repository and I am recording milestones by revision
> number, not 'tags'. It works fine.
Are you saying that you don't use tags at all? What if you want to do a
checkout of a named revision, e.g. "release-0.9"? And normally, one
would want tags to apply on a per-project basis; e.g. "release-0.9" of
one project might co-exist with "alpha-release" and "dotnet-test" in
other projects. So you can't sensibly tag the entire repository with a
particular tag name; you have to copy prject subtrees into named tag
directories, which I would say is very prone to human error (even though
it probably is not in itself incorrect)...From what you say, you must be
managing a separate file of tags and revisions.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Scott Palmer <sc...@2connected.org>.
On 1-Aug-05, at 5:41 AM, Thomas Beale wrote:
> I haven't had the time to think an architectural solution through,
> but all this sounds very reasonable. One thing I am fairly sure of:
> there would not be any "tags" directory; I would simply record the
> tag against the revision number being tagged. Of course this
> mitigates against using multiple project trees in one repository,
> which I initially thought sounded good, but in the end I think is
> unusable; it has to be one project per repository. Doing otherwise
> renders the versioning across the board completely meaningless, and
> means that svn really is just a versioned file-system (and I'm not
> knocking that!).
I don't follow. I am currently using subversion with multiple
projects per repository and I am recording milestones by revision
number, not 'tags'. It works fine.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <Th...@OceanInformatics.biz>.
Matthew Sanderson wrote:
>Hi Thomas,
>
>
>
>But from the point of view of a versioned filesystem, there is no
>difference in the semantics of these two directories in the versioned
>filesystem tree. The precise location in the versioned virtual filesystem
>tree of a specific variation on a given file is irrelevant for the
>purposes of efficient storage of all the different versions of that file
>in all locations plus their inter-relationships. SVN supplies mechanism.
>SVN knows nothing of your policy, formal semantics or development
>methodologies, and I claim it should never be made to know of them.
>
>
Agree; what is in the real server back-end should probably be just what
it is today. I just would not use that mechanism to implement the
semantics of branches, tags etc...
>However as you say, the 'true filesystem' content directories as seen in a
>WC and the 'virtual filesystem' meta-content directories as seen in the
>server's repository structure are very different types of object when seen
>from a SCM point of view. At this level of abstraction they do have
>different semantics. But that has little to do with SVN any longer; that's
>policy of an SCM, not mechanism of a versioned filesystem.
>
>
also agree...
>So this is not (as you said earlier) a confusion in SVN between two
>different concepts, which could lead to bugs etc down the track. Instead,
>at the level of abstraction at which SVN currently operates, there is
>simply no distinction between these two concepts, and therefore there is
>no design flaw inherent in treating them identically in SVN as it
>currently stands. Do you agree? Or so you still see this as a
>confusion and/or design bug in SVN?
>
>
well, I see it as an attempt to implement semantics in a very
approximate way in SVN's currently versioned fle system facility (likely
to cause problems) when such semantics should realy be implemented
elsewher - in another server layer, in the client or whatever.
>In your latest message, you appear to be arguing:
>1. I need a software configuration management system.
>2. SVN is only a version control system, not a full SCM.
>3. Therefore, SVN should become a full SCM system.
>
>
well, not necessarily the last - it may be up to other groups to build
other layers. But on the other hand the subversion people do publish in
their book the file-system implementation of branches and tags, which
indicates they are thinking about such issues.
>By this argument, we would soon end up with the kernel and all apps
>statically linked together in one address space. I'm sure you'll agree
>that modularity leads to better quality software, so a better argument is:
>
>1. I need a software configuration management system.
>2. SVN is only a version control system, not a full SCM.
>3. But umodified SVN can be used as a base on which to implement SCM.
>4. Therefore, SVN should be used as a base for higher SCM layers.
>
>
I alreayd suggested this in another post (maybe it was not clear
enough). But I agree anyway.
>Then the SVN and SCM layers can be more easily debugged and tested.
>
>
I would never suggest anyhting else. This discussion, from my point of
view is about requirements, not (ye) about architecture.
......
>A better design, though, would be to merge your CM tier into your client
>tier, in a new client app. There would be a new layer between the
>top-level UI, and the RA layer, which would enforce policy. Much of the
>RA layer's functionality would be hidden and aggregated together into
>even-higher-level operations of the sort you want, and then only those
>even-higher-level operations would be accessible from the client UI.
>For example a 'release' operation, which just knows the policy for
>where in the repository tree release tags live, as opposed to
>TortoiseSVN's branch/tag operation, which gives you the unfortunate
>freedom to violate site policy by creating tags in the wrong place.
>One single client policy configuration file should describe the project
>structure, map the project structure to the repository structure, and
>describe the allowed workflow.
>
>
I haven't had the time to think an architectural solution through, but
all this sounds very reasonable. One thing I am fairly sure of: there
would not be any "tags" directory; I would simply record the tag against
the revision number being tagged. Of course this mitigates against using
multiple project trees in one repository, which I initially thought
sounded good, but in the end I think is unusable; it has to be one
project per repository. Doing otherwise renders the versioning across
the board completely meaningless, and means that svn really is just a
versioned file-system (and I'm not knocking that!).
>I encourage you to create such a client program. With reference to the
>TortoiseSVN source for guidance, it should not be too difficult or
>time-consuming.
>
>Generally, if your needs can be satisfied solely by adding more
>functionality on top of subversion (without actually changing subversion
>itself), then you have not thereby necessarily discovered a design flaw in
>Subversion, don't you agree?
>
>
I don't think there is a design flaw in subversion, but I do think there
is a flaw in the design thinking of the total solution to implement
trunk/branches/tags as plain old directories.
>Instead, you have discovered a way to use svn plus some extra
>functionality to address problems that svn (by design) does not currently
>attempt (and should never attempt IMO) to address.
>
>
which I agree is the correct way to see things. When I have time, I will
indeed consider how this functionality can be added, and share it with
the group.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Brian Huddleston <br...@huddleston.net>.
This is certainly an interesting argument about levels of abstraction. :-)
Subversions is a versioned file system.
* It is lower level than CVS (which has branches and tags).
* It is lower level than perforce (which has branches and tags).
* It is lower level than ClearCase (which has branches and tages).
* It is lower level than Visual SourceSafe (which has branches and tags).
I'm not sure the Subversion devs would agree with that, however much they've
convinced themselves that tags and branches are not cornerstones of proper
version control but simply Wrong Thinking(tm).
Someone should enlighten all those poor users of other systems that they
needn't be bound by silly inflexible branches and tags. They can have much
more "flexibility" by simply copying directories around. I don't know why
no one has thought of it before! :-)
-Brian
----- Original Message -----
> Generally, if your needs can be satisfied solely by adding more
> functionality on top of subversion (without actually changing subversion
> itself), then you have not thereby necessarily discovered a design flaw in
> Subversion, don't you agree?
> Instead, you have discovered a way to use svn plus some extra
> functionality to address problems that svn (by design) does not currently
> attempt (and should never attempt IMO) to address.
>
> Regards,
>
> --m@
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Matthew Sanderson <ma...@formtrap.com>.
Hi Thomas,
On Sat, 30 Jul 2005, Thomas Beale wrote:
> Robert P. J. Day wrote:
> > On Sat, 30 Jul 2005, Thomas Beale wrote:
> >
> > as more than one person has pointed out, there's nothing magical about
> > directories named "Branches" or "Tags" or "Releases" -- it's all in
> > the way you treat them, that's all.
>
> But there should. The formal semantics of these directories are not
> those of a normal project directory; they are there to separate out
> different branches of development, and also to implement tags. But the
> semantics of these things are not the semantics of directories.
But from the point of view of a versioned filesystem, there is no
difference in the semantics of these two directories in the versioned
filesystem tree. The precise location in the versioned virtual filesystem
tree of a specific variation on a given file is irrelevant for the
purposes of efficient storage of all the different versions of that file
in all locations plus their inter-relationships. SVN supplies mechanism.
SVN knows nothing of your policy, formal semantics or development
methodologies, and I claim it should never be made to know of them.
However as you say, the 'true filesystem' content directories as seen in a
WC and the 'virtual filesystem' meta-content directories as seen in the
server's repository structure are very different types of object when seen
from a SCM point of view. At this level of abstraction they do have
different semantics. But that has little to do with SVN any longer; that's
policy of an SCM, not mechanism of a versioned filesystem.
So this is not (as you said earlier) a confusion in SVN between two
different concepts, which could lead to bugs etc down the track. Instead,
at the level of abstraction at which SVN currently operates, there is
simply no distinction between these two concepts, and therefore there is
no design flaw inherent in treating them identically in SVN as it
currently stands. Do you agree? Or so you still see this as a
confusion and/or design bug in SVN?
In your latest message, you appear to be arguing:
1. I need a software configuration management system.
2. SVN is only a version control system, not a full SCM.
3. Therefore, SVN should become a full SCM system.
By this argument, we would soon end up with the kernel and all apps
statically linked together in one address space. I'm sure you'll agree
that modularity leads to better quality software, so a better argument is:
1. I need a software configuration management system.
2. SVN is only a version control system, not a full SCM.
3. But umodified SVN can be used as a base on which to implement SCM.
4. Therefore, SVN should be used as a base for higher SCM layers.
Then the SVN and SCM layers can be more easily debugged and tested.
AFAICS, if you really need your policy to be enforced in software at some
level, not just adhered to because of sufficient user training, then this
all necessitates just the sort of breakdown you describe:
> - bottom layer: subversion as it is now (don't touch it!)
> - Configuration Management semantics layer: a layer which uses the
> subversion version controlled file system to store data, but adds CM
> semantics, rather like BitKeeper does (it just uses SCCS files in fact,
> plus a whole lot of control data, and makes it look like multiple
> parallel branches all going on
> - front-end (client) layer: where configuration / localisation of
> workflow, process, branche types etc is done.
>
> I guess the way I would implement the CM semantics I think should exist
> would be an independent (optional) architectural layer on top of
> subversion's backend.
It seems to me that if you only used the command-line client, your middle
tier could be at minimum a bunch of fairly trivial shell scripts of the
sort that someone else just posted. Do you want a copy of our wrapper
scripts too? They're pretty similar. They're *very* easy to use.
A better design, though, would be to merge your CM tier into your client
tier, in a new client app. There would be a new layer between the
top-level UI, and the RA layer, which would enforce policy. Much of the
RA layer's functionality would be hidden and aggregated together into
even-higher-level operations of the sort you want, and then only those
even-higher-level operations would be accessible from the client UI.
For example a 'release' operation, which just knows the policy for
where in the repository tree release tags live, as opposed to
TortoiseSVN's branch/tag operation, which gives you the unfortunate
freedom to violate site policy by creating tags in the wrong place.
One single client policy configuration file should describe the project
structure, map the project structure to the repository structure, and
describe the allowed workflow.
I encourage you to create such a client program. With reference to the
TortoiseSVN source for guidance, it should not be too difficult or
time-consuming.
Generally, if your needs can be satisfied solely by adding more
functionality on top of subversion (without actually changing subversion
itself), then you have not thereby necessarily discovered a design flaw in
Subversion, don't you agree?
Instead, you have discovered a way to use svn plus some extra
functionality to address problems that svn (by design) does not currently
attempt (and should never attempt IMO) to address.
Regards,
--m@
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
Robert P. J. Day wrote:
> On Sat, 30 Jul 2005, Thomas Beale wrote:
>
> as more than one person has pointed out, there's nothing magical about
> directories named "Branches" or "Tags" or "Releases" -- it's all in
> the way you treat them, that's all.
But there should. The formal semantics of these directories are not
those of a normal project directory; they are there to separate out
different branches of development, and also to implement tags. But the
semantics of these things are not the semantics of directories.
Rather than argue this point to death however, consider an architecture
like the following:
- bottom layer: subversion as it is now (don't touch it!)
- Configuration Management semantics layer: a layer which uses the
subversion version controlled file system to store data, but adds CM
semantics, rather like BitKeeper does (it just uses SCCS files in fact,
plus a whole lot of control data, and makes it look like multiple
parallel branches all going on
- front-end (client) layer: where configuration / localisation of
workflow, process, branche types etc is done.
I guess the way I would implement the CM semantics I think should exist
would be an independent (optional) architectural layer on top of
subversion's backend.
>
> and while any client tool would most likely want to have some
> pre-defined set of perspectives like main, branches, tags and so on,
'perspectives' is exactly the word I was looking for.
> the directory structure effortlessly let's you define certain views of
> the repository as, say, "Rob's Wild and Crazy Ideas" and stuff like
> that.
>
> will your hypothetical client tool be able to handle that kind of
> flexibility?
>
> rday
"Rob's wild and crazy ideas" would probably be the name of a branch in
the 'branches' perspective, but there is no reason why people couldn't
invent their own perspective names as well.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by "Robert P. J. Day" <rp...@mindspring.com>.
On Sat, 30 Jul 2005, Thomas Beale wrote:
> Frank Gruman wrote:
> > All in all, I think the subversion developers are approaching it
> > properly in allowing freedom of repository layout. If you do want
> > something more 'standardized', I think I saw another post
> > referring to building a __client__ that enforced whatever
> > structure you want. That's the beauty - you can take the server
> > and data inside of it and put whatever top end on it you want.
> > But not at the server level.
>
> I think that one obvious way to implement what I am suggesting is
> indeed in client tools.
i might be missing your point but i see one possible issue with your
moving the support for branching/tagging/whatever into the client
tools, rather than just leaving it where it is as part of the regular
directory structure.
as more than one person has pointed out, there's nothing magical about
directories named "Branches" or "Tags" or "Releases" -- it's all in
the way you treat them, that's all.
and while any client tool would most likely want to have some
pre-defined set of perspectives like main, branches, tags and so on,
the directory structure effortlessly let's you define certain views of
the repository as, say, "Rob's Wild and Crazy Ideas" and stuff like
that.
will your hypothetical client tool be able to handle that kind of
flexibility?
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
Frank Gruman wrote:
> Your point is an interesting one, but I too would have to disagree with
> your stance of creating a 'defacto standard'. In my development
> environment, it made more sense to change the names of the directory
> structure. No one in our development team understood what a 'trunk'
> was, or branches, or tags. So we called ours Main, Beta, and Releases.
Ah - but this exactly what I want. I only used the words "trunk",
"branches" etc because that is what is in the Subversion. I of course
think that support for this kind of thing allow local naming of these
concepts. Personally, I would prefer main/branches/releases. Tags is a
different concept - they are named baselines, so should be implemented
differently. But the names don't matter. WHat matters is having:
- a mainline development space containing a file tree
- N x named branch development spaces, each of whose tree is derived
from some other file tree, usually the mainline, but need not be
- M x name release development spaces, each of whose tree is almost
certainly derived from the state of the tree in the mainline space at
some revision
- the ability to tag any state of the file tree in any of these spaces
with a symbolic name.
> Most of the work is done on Main. When we get to a build, that code
> goes to Beta so that Main line future functionality can continue while
> testing is run. If there are bugs found in testing, they get fixed on
> Beta and eventually merged into Main. Once we get to a good point
> there, things go to Releases. Only managers are allowed to make any
> changes to Releases. I could also restrict Beta, but our dev team
> rotates through Beta dev fixing and mainline dev.
This sounds like very normal and good process to me.
> It works for us. That's what I really like about Subversion. It
> allowed us to set it up in a way that made sense to us. We didn't have
> to learn some other guys' idea of what a repository structure should
> be. I control access to things through pre-commit hooks and
> mod_auth_svn. My developers have fallen in love with cheap copies. It
> took me a couple of tries, but I have integration between my
> repositories and Bugzilla, so no commit can be done without some sort of
> Bug / Issue # being attached for all of the documentation of why changes
> are made. The more I talk about it, the more I love what Subversion has
> allowed me to do.
I agree it allows a lot of things. I just feel this is one area where it
could provide cleaner (still flexible) support for process - not just
using file system directories.
> All in all, I think the subversion developers are approaching it
> properly in allowing freedom of repository layout. If you do want
> something more 'standardized', I think I saw another post referring to
> building a __client__ that enforced whatever structure you want. That's
> the beauty - you can take the server and data inside of it and put
> whatever top end on it you want. But not at the server level.
I think that one obvious way to implement what I am suggesting is indeed
in client tools.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Frank Gruman <fg...@verizon.net>.
Hi Matt,
I kludged together a couple of other commit scripts that I had found in
various other places, and came up with the one I am using.
It's not pretty, but it works for us, for now. I have had more exposure
to perl since, and I need to rewrite it, but you can pull my last
version of the script here:
http://www2.thegrumans.net:8888/projects/svn/commit-mysql.pl.
<http://www2.thegrumans.net:8888/projects/svn/commit-mysql.pl>
This dumps the data into Bugzilla as a comment, and takes each file
modified and turns it into a link for ViewCVS to read.
On the subversion side, we are using TortoiseSVN, and I added the
bugtraq properties to link the commit comments to Bugzilla. For most
situations, this has worked very well. Since we typically perform one
commit per bug fix, I haven't tested this with multiple bugs in the bug
list.
If you need more detail feel free to email me offline, or (better yet,
and for all the others) start a new thread since this one isn't exactly
on topic. I had a thread going here
(http://svn.haxx.se/users/archive-2005-04/1896.shtml) if you feel you
want to continue that one.
Good luck!
Frank
Matthew Sanderson wrote:
>Hi Frank,
>
>+1 for arguments against the probably-illusory 'defacto standard'.
>
>What sort of integration did you make with Bugzilla, and how did you do
>it, may I ask?
>We may drop Bugzilla (we're not terribly happy with it). But if we do
>stick with it, close integration with svn would be nice to have.
>
>Cheers,
>
>--matt
>
>Matthew Sanderson
>Senior Programmer (UNIX)
>TCG Information Systems Pty Ltd
>Sydney, Australia
>matthew@formtrap.com
>http://www.formtrap.com/
>+61 (02) 8303 2407
>
>On Fri, 29 Jul 2005, Frank Gruman wrote:
>
>
>
>>Your point is an interesting one, but I too would have to disagree with
>>your stance of creating a 'defacto standard'. In my development
>>environment, it made more sense to change the names of the directory
>>structure. No one in our development team understood what a 'trunk'
>>was, or branches, or tags. So we called ours Main, Beta, and Releases.
>>Most of the work is done on Main. When we get to a build, that code
>>goes to Beta so that Main line future functionality can continue while
>>testing is run. If there are bugs found in testing, they get fixed on
>>Beta and eventually merged into Main. Once we get to a good point
>>there, things go to Releases. Only managers are allowed to make any
>>changes to Releases. I could also restrict Beta, but our dev team
>>rotates through Beta dev fixing and mainline dev.
>>
>>It works for us. That's what I really like about Subversion. It
>>allowed us to set it up in a way that made sense to us. We didn't have
>>to learn some other guys' idea of what a repository structure should
>>be. I control access to things through pre-commit hooks and
>>mod_auth_svn. My developers have fallen in love with cheap copies. It
>>took me a couple of tries, but I have integration between my
>>repositories and Bugzilla, so no commit can be done without some sort of
>>Bug / Issue # being attached for all of the documentation of why changes
>>are made. The more I talk about it, the more I love what Subversion has
>>allowed me to do.
>>
>>All in all, I think the subversion developers are approaching it
>>properly in allowing freedom of repository layout. If you do want
>>something more 'standardized', I think I saw another post referring to
>>building a __client__ that enforced whatever structure you want. That's
>>the beauty - you can take the server and data inside of it and put
>>whatever top end on it you want. But not at the server level.
>>
>>Don't change my Subverion... :-)
>>
>>Regards,
>>Frank
>>
>>Thomas Beale wrote:
>>
>>
>>
>>>Jacob Atzen wrote:
>>>
>>>
>>>
>>>>On Fri, Jul 29, 2005 at 10:28:42AM +0100, Thomas Beale wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Sure, and that is of course our advice in our help pages. But it
>>>>>doesn't mean that people will understand that these directories are
>>>>>special; it is not always easy to educate users who are not familiar
>>>>>with CM systems what trunk/tags/branches are about; some expect it to
>>>>>be built in, others don't understand at all to begin with.
>>>>>
>>>>>
>>>>>
>>>>There's just no substitue for education. If your developer don't
>>>>understand it initially they _will_ have to learn. There's no tool in
>>>>the world that will do this for you.
>>>>You say you have a "releases" branch which only bugfixes should be
>>>>committed to. This is only achievable by human means, no machine is able
>>>>to determine wether a certain patch is a bugfix or a new feature and
>>>>therefore no software will ever be able to enforce this rule.
>>>>
>>>>
>>>>
>>>>
>>>Apparently I have not explained myself sufficiently clearly...what I
>>>am suggesting is that knowledge of the directories
>>>trunk/tags/branches/release be built into the tools at the client end.
>>>This would be done in such a way that they would no longer appear in
>>>the 'normal' directory hierarchy but instead would (for example)
>>>display the contents of those directories as views, or in some other
>>>way. Then other rules could be attached to those views, such as the
>>>rule that the tags view is readonly after creation and so on. Doing
>>>this just enables the machine to implement the discipline instead of
>>>humans having to do it, which is the current case. It would be easy
>>>enough to switch it off for users who wanted to not have such a
>>>feature, so it would not be a straitjacket. But if it were there, I
>>>think most users would choose to use it.
>>>
>>>- thomas beale
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>>For additional commands, e-mail: users-help@subversion.tigris.org
>>>
>>>
>>>
>>>
>
>
>
Re: early reflections on subversion methodology
Posted by Matthew Sanderson <ma...@formtrap.com>.
Hi Frank,
+1 for arguments against the probably-illusory 'defacto standard'.
What sort of integration did you make with Bugzilla, and how did you do
it, may I ask?
We may drop Bugzilla (we're not terribly happy with it). But if we do
stick with it, close integration with svn would be nice to have.
Cheers,
--matt
Matthew Sanderson
Senior Programmer (UNIX)
TCG Information Systems Pty Ltd
Sydney, Australia
matthew@formtrap.com
http://www.formtrap.com/
+61 (02) 8303 2407
On Fri, 29 Jul 2005, Frank Gruman wrote:
> Your point is an interesting one, but I too would have to disagree with
> your stance of creating a 'defacto standard'. In my development
> environment, it made more sense to change the names of the directory
> structure. No one in our development team understood what a 'trunk'
> was, or branches, or tags. So we called ours Main, Beta, and Releases.
> Most of the work is done on Main. When we get to a build, that code
> goes to Beta so that Main line future functionality can continue while
> testing is run. If there are bugs found in testing, they get fixed on
> Beta and eventually merged into Main. Once we get to a good point
> there, things go to Releases. Only managers are allowed to make any
> changes to Releases. I could also restrict Beta, but our dev team
> rotates through Beta dev fixing and mainline dev.
>
> It works for us. That's what I really like about Subversion. It
> allowed us to set it up in a way that made sense to us. We didn't have
> to learn some other guys' idea of what a repository structure should
> be. I control access to things through pre-commit hooks and
> mod_auth_svn. My developers have fallen in love with cheap copies. It
> took me a couple of tries, but I have integration between my
> repositories and Bugzilla, so no commit can be done without some sort of
> Bug / Issue # being attached for all of the documentation of why changes
> are made. The more I talk about it, the more I love what Subversion has
> allowed me to do.
>
> All in all, I think the subversion developers are approaching it
> properly in allowing freedom of repository layout. If you do want
> something more 'standardized', I think I saw another post referring to
> building a __client__ that enforced whatever structure you want. That's
> the beauty - you can take the server and data inside of it and put
> whatever top end on it you want. But not at the server level.
>
> Don't change my Subverion... :-)
>
> Regards,
> Frank
>
> Thomas Beale wrote:
>
> > Jacob Atzen wrote:
> >
> >> On Fri, Jul 29, 2005 at 10:28:42AM +0100, Thomas Beale wrote:
> >>
> >>
> >>> Sure, and that is of course our advice in our help pages. But it
> >>> doesn't mean that people will understand that these directories are
> >>> special; it is not always easy to educate users who are not familiar
> >>> with CM systems what trunk/tags/branches are about; some expect it to
> >>> be built in, others don't understand at all to begin with.
> >>>
> >>
> >>
> >> There's just no substitue for education. If your developer don't
> >> understand it initially they _will_ have to learn. There's no tool in
> >> the world that will do this for you.
> >> You say you have a "releases" branch which only bugfixes should be
> >> committed to. This is only achievable by human means, no machine is able
> >> to determine wether a certain patch is a bugfix or a new feature and
> >> therefore no software will ever be able to enforce this rule.
> >>
> >>
> >
> > Apparently I have not explained myself sufficiently clearly...what I
> > am suggesting is that knowledge of the directories
> > trunk/tags/branches/release be built into the tools at the client end.
> > This would be done in such a way that they would no longer appear in
> > the 'normal' directory hierarchy but instead would (for example)
> > display the contents of those directories as views, or in some other
> > way. Then other rules could be attached to those views, such as the
> > rule that the tags view is readonly after creation and so on. Doing
> > this just enables the machine to implement the discipline instead of
> > humans having to do it, which is the current case. It would be easy
> > enough to switch it off for users who wanted to not have such a
> > feature, so it would not be a straitjacket. But if it were there, I
> > think most users would choose to use it.
> >
> > - thomas beale
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Frank Gruman <fg...@verizon.net>.
Your point is an interesting one, but I too would have to disagree with
your stance of creating a 'defacto standard'. In my development
environment, it made more sense to change the names of the directory
structure. No one in our development team understood what a 'trunk'
was, or branches, or tags. So we called ours Main, Beta, and Releases.
Most of the work is done on Main. When we get to a build, that code
goes to Beta so that Main line future functionality can continue while
testing is run. If there are bugs found in testing, they get fixed on
Beta and eventually merged into Main. Once we get to a good point
there, things go to Releases. Only managers are allowed to make any
changes to Releases. I could also restrict Beta, but our dev team
rotates through Beta dev fixing and mainline dev.
It works for us. That's what I really like about Subversion. It
allowed us to set it up in a way that made sense to us. We didn't have
to learn some other guys' idea of what a repository structure should
be. I control access to things through pre-commit hooks and
mod_auth_svn. My developers have fallen in love with cheap copies. It
took me a couple of tries, but I have integration between my
repositories and Bugzilla, so no commit can be done without some sort of
Bug / Issue # being attached for all of the documentation of why changes
are made. The more I talk about it, the more I love what Subversion has
allowed me to do.
All in all, I think the subversion developers are approaching it
properly in allowing freedom of repository layout. If you do want
something more 'standardized', I think I saw another post referring to
building a __client__ that enforced whatever structure you want. That's
the beauty - you can take the server and data inside of it and put
whatever top end on it you want. But not at the server level.
Don't change my Subverion... :-)
Regards,
Frank
Thomas Beale wrote:
> Jacob Atzen wrote:
>
>> On Fri, Jul 29, 2005 at 10:28:42AM +0100, Thomas Beale wrote:
>>
>>
>>> Sure, and that is of course our advice in our help pages. But it
>>> doesn't mean that people will understand that these directories are
>>> special; it is not always easy to educate users who are not familiar
>>> with CM systems what trunk/tags/branches are about; some expect it to
>>> be built in, others don't understand at all to begin with.
>>>
>>
>>
>> There's just no substitue for education. If your developer don't
>> understand it initially they _will_ have to learn. There's no tool in
>> the world that will do this for you.
>> You say you have a "releases" branch which only bugfixes should be
>> committed to. This is only achievable by human means, no machine is able
>> to determine wether a certain patch is a bugfix or a new feature and
>> therefore no software will ever be able to enforce this rule.
>>
>>
>
> Apparently I have not explained myself sufficiently clearly...what I
> am suggesting is that knowledge of the directories
> trunk/tags/branches/release be built into the tools at the client end.
> This would be done in such a way that they would no longer appear in
> the 'normal' directory hierarchy but instead would (for example)
> display the contents of those directories as views, or in some other
> way. Then other rules could be attached to those views, such as the
> rule that the tags view is readonly after creation and so on. Doing
> this just enables the machine to implement the discipline instead of
> humans having to do it, which is the current case. It would be easy
> enough to switch it off for users who wanted to not have such a
> feature, so it would not be a straitjacket. But if it were there, I
> think most users would choose to use it.
>
> - thomas beale
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: early reflections on subversion methodology
Posted by Thomas Beale <Th...@OceanInformatics.biz>.
Jacob Atzen wrote:
>On Fri, Jul 29, 2005 at 10:28:42AM +0100, Thomas Beale wrote:
>
>
>>Sure, and that is of course our advice in our help pages. But it
>>doesn't mean that people will understand that these directories are
>>special; it is not always easy to educate users who are not familiar
>>with CM systems what trunk/tags/branches are about; some expect it to
>>be built in, others don't understand at all to begin with.
>>
>>
>
>There's just no substitue for education. If your developer don't
>understand it initially they _will_ have to learn. There's no tool in
>the world that will do this for you.
>
>You say you have a "releases" branch which only bugfixes should be
>committed to. This is only achievable by human means, no machine is able
>to determine wether a certain patch is a bugfix or a new feature and
>therefore no software will ever be able to enforce this rule.
>
>
Apparently I have not explained myself sufficiently clearly...what I am
suggesting is that knowledge of the directories
trunk/tags/branches/release be built into the tools at the client end.
This would be done in such a way that they would no longer appear in the
'normal' directory hierarchy but instead would (for example) display the
contents of those directories as views, or in some other way. Then other
rules could be attached to those views, such as the rule that the tags
view is readonly after creation and so on. Doing this just enables the
machine to implement the discipline instead of humans having to do it,
which is the current case. It would be easy enough to switch it off for
users who wanted to not have such a feature, so it would not be a
straitjacket. But if it were there, I think most users would choose to
use it.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Jacob Atzen <ja...@aub.dk>.
On Fri, Jul 29, 2005 at 10:28:42AM +0100, Thomas Beale wrote:
> Sure, and that is of course our advice in our help pages. But it
> doesn't mean that people will understand that these directories are
> special; it is not always easy to educate users who are not familiar
> with CM systems what trunk/tags/branches are about; some expect it to
> be built in, others don't understand at all to begin with.
There's just no substitue for education. If your developer don't
understand it initially they _will_ have to learn. There's no tool in
the world that will do this for you.
You say you have a "releases" branch which only bugfixes should be
committed to. This is only achievable by human means, no machine is able
to determine wether a certain patch is a bugfix or a new feature and
therefore no software will ever be able to enforce this rule.
Unless you can come up with some machine verifiable rules as to what
goes into which directory you're just plain out of luck. Now if on the
other hand you can come up with some machine verifiable rules then
Subversion actually already has a system in place to enforce those rules
through the pre-commit script.
I've heard of people enforcing a rule of "only valid HTML is to be
commited" in Subversion and enforcing this automatically. Which IMHO
goes to show the strength of the current Subversion design.
A partial solution to your problem might be to limit the number of
people with write access to certain parts of the tree. You could grant
everyone write on trunk, make a "bugfixers" group for your release tree
and a "release-engineer" group for the tags tree.
Quite a few people on this list also like to make sure that you can't
update a tagged version. This can be done by pre-commit hooks.
And finally remember that Subversion never forgets - changes can always
be undone.
--
Cheers,
- Jacob Atzen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
Saulius Grazulis wrote:
> On Friday 29 July 2005 03:42, Steve Williams wrote:
>
>
>
> Actually, you can hide the directory of your project structure for developers
> without any modification of the client:
>
> Instead of checking out the whole repository:
>
> svn co svn://server.domain.org/repositories/project1 whole-project1
>
> You can just check out a trunk:
>
> svn co svn://server.domain.org/repositories/project1/trunk project1
>
> Or some branch:
Sure, and that is of course our advice in our help pages. But it doesn't
mean that people will understand that these directories are special; it
is not always easy to educate users who are not familiar with CM systems
what trunk/tags/branches are about; some expect it to be built in,
others don't understand at all to begin with.
>
> svn co svn://server.domain.org/repositories/project1/RELEASE/version-11R6
> project1-view-11R6
>
> At your liking... :)
>
> You can also switch your working copy between any of the branches, tags or
> trunk.
>
> Enforcement of the directory structure is a matter of project administration.
At this stage of subversion's development, you are right; because there
is no other choice. But it would be nice if a facility were built into
the tool to e.g. make a trunk/tags/releases/branches directory "node" at
some point in your tree, and have svn manage that itself, and not sow
those as directories, but as a 'developmnet tree' or somesuch.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Saulius Grazulis <gr...@akl.lt>.
On Friday 29 July 2005 03:42, Steve Williams wrote:
> > ... 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.
>...
> As for clients hiding those directories, you would have to customize one
> of the many available clients (they are open-source after all) since
> what you are trying to hide is your own idea of a "real development"
> directory structure.
Actually, you can hide the directory of your project structure for developers
without any modification of the client:
Instead of checking out the whole repository:
svn co svn://server.domain.org/repositories/project1 whole-project1
You can just check out a trunk:
svn co svn://server.domain.org/repositories/project1/trunk project1
Or some branch:
svn co svn://server.domain.org/repositories/project1/RELEASE/version-11R6
project1-view-11R6
At your liking... :)
You can also switch your working copy between any of the branches, tags or
trunk.
Enforcement of the directory structure is a matter of project administration.
It is a very nice feature of Subversion that it does *not* impose any
directory structure on you. This was one of the reasons I chose Subversion...
Well, except for the need to have trunk/||tags/||branches/||, which is a very
mild requirement ;).
--
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
Martin Tomes wrote:
>
>
> Subversion (like CVS) isn't a Configuration Management System, it is a
> revision control system. A proper CMS would include issue trackers,
> build systems... the list goes on.
right. And I would not expect all the functionality of a ClearCase or
BitKeeper, but on the other hand, svn is much easier to use for some
things than BK was, so don't get me wrong, for what it is, it's very
good. I just have a feeling that a little bit more tool support in the
subversion level would go a long way to making a whole CM environment
based on it easier to deploy.
>
> Have you looked at Trac? It gives you some of this, but you will still
> have to provide standards to work to and build tools yourself.
>
I presume itis an issue tracker of some kind? I had a look at the web
page of scarab (http://scarab.tigris.org/) which in concept at least is
appealing since presumably it is nicely integrated with svn. Anyone have
any experience with it? We want configurable workflows (i.e. state
machines) and fully configurable fields.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Martin Tomes <li...@tomes.org>.
Thomas Beale wrote:
> Miha Vitorovic wrote:
>
>> news <ne...@sea.gmane.org> wrote on 29.07.2005 11:23:16:
>> I see your point, but don't buy it. You argue, that the tool is bad,
>> because it does not force everyone to "do things the right way" (even
>> though the jury is still out on what "the right way" is).
>
> I have not said that the tools is bad, quite the reverse. If I thought
> itwas bad, our community of hundreds of developers would not be using
> it. What I said was that it does not go the full way to implementing
> some desirable CM behaviour.
Subversion (like CVS) isn't a Configuration Management System, it is a
revision control system. A proper CMS would include issue trackers,
build systems... the list goes on.
Have you looked at Trac? It gives you some of this, but you will still
have to provide standards to work to and build tools yourself.
--
Martin Tomes
echo 'martin at tomes x org x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'
Visit http://www.subversionary.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Miha Vitorovic <mv...@nil.si>.
Thomas Beale <Th...@OceanInformatics.biz> wrote on 29.07.2005
12:59:51:
> Miha Vitorovic wrote:
>
> it's not about _making_ people do things; there is no problem with
> people wanting to do the right thing; the challenge is to prevent them
> from making unintended errors (e.g. moving or renaming the tags
> directory, or modifying its contents).
Yes, I agree. And my (somewhat heated) argument was, that allowing to do
so only to those people who want it, is the way to go. And this is what
Subversion does.
Cheers,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <Th...@OceanInformatics.biz>.
Miha Vitorovic wrote:
>news <ne...@sea.gmane.org> wrote on 29.07.2005 11:23:16:
>
>
>
>
>
>I see your point, but don't buy it. You argue, that the tool is bad,
>because it does not force everyone to "do things the right way" (even
>though the jury is still out on what "the right way" is).
>
I have not said that the tools is bad, quite the reverse. If I thought
itwas bad, our community of hundreds of developers would not be using
it. What I said was that it does not go the full way to implementing
some desirable CM behaviour.
>But this is a
>generic tool, that can be easily (if not without some work) enhanced to so
>exactly what you want. Or do whatever somebody else wants, in a different
>way. On the other hand, if its structure was locked to your way of doing
>things, than it would force all other "real developers" to do things just
>one way. And maybe, by being more open, somebody will come up with an even
>better way of doing things.
>
>
well, it ain't "my" way: clearly it's the "way" of a lot of people,
since the the trunk/tags/branches schema is published in the subversion
book and is put about as received wisdom (and in my experience, it is
more or less so). No, this is nothing to do with me; this is just about
supporting a bit more formally the defacto way of doing such things. My
only addition was a "releases" directory, and the fact that we
capitalise those directory names in our subversion instances.
>But beside that, if you can not make your users/developers conform to your
>standards, than you have organizational problems, not software problems.
>
>
it's not about _making_ people do things; there is no problem with
people wanting to do the right thing; the challenge is to prevent them
from making unintended errors (e.g. moving or renaming the tags
directory, or modifying its contents).
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Miha Vitorovic <mv...@nil.si>.
news <ne...@sea.gmane.org> wrote on 29.07.2005 11:23:16:
> Steve Williams wrote:
> > Thomas Beale wrote:
> >
> >> I have used many CM systems, and have been thinking about whether
> >> subversion supports the kinds of processes needed in real
development,
> >> particularly release management. I think that the basic advice of
> >> using the trunk/tags/branches directories is ok, but does not go far
> >> enough.
> >
> >
> > That is, "real development" in your world of real development.
> > Everyone's world of real development is slightly different. The above
> > statement made it sound like Subversion is a toy versioning system not
> > used in "real development".
>
> Well I would say it is a good versioned file system implementation at
> this stage - very good in fact. But it doesn't have any built in support
> for branching or tagging, only lazy copying, which goes a go way to
> making it work, but otherwise the facility is manual. This means it is
> ad hoc, and no users or tools can make any assumptions about how
> branches, tags etc work.
>
> By "real" development I just meant any development that actually has a
> wide user base, issue tracking lists, change requests to document
> changes, and identified releases. I'm sure you will agree that it is
> perfectly possible to build (great) software without all these things;
> however such limited process usually corresponds to a small closed team
> (e.g. an experimental academic development) or a sole developer.
>
> >>
> >> 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.
> >
> >
> > Subversion does not impose any directory structure on you. Subversion
> > supports whatever directory structure you want. If I wanted to, I
could
> > have a directory structure like this:
> >
> > - foo
> > - BAR
> > - pOoP
>
> sure; and that's the problem/challenge at hand - imposing some standard
> thinking on this. Consider it this way: if subversion's revisioning
> really works (I mean: there are 0 bugs in the versioned representation
> of files) - and as far as I can see, it is 99% there - then its
> versioned representation of a directory tree is half-way to a defacto
> standard representation of versioned hierarchical data. This hasn't
> previously existed (well, CVS was there, but not very good at
> representing changes other than to content of files; otherwise you had
> closed things like VMS's versioning file system); if we went a bit
> further and the community agreed a generic methodology about branching,
> tagging and releasing, then that methodology could be introduced into
> the tools as well. Such methodology is pretty well known in the world of
> CM and is built into most commercial tools. It seems to me that
> Subversion could be first off the block to both implement _and_
> standardise it.
>
> >
> > and Subversion would still work as wonderfully as it does with the
> > defacto standard of trunk, branches, tags. Uppercase, lowercase,
> > naming. It is totally up to you.
> >
> > As for clients hiding those directories, you would have to customize
one
> > of the many available clients (they are open-source after all) since
> > what you are trying to hide is your own idea of a "real development"
> > directory structure.
>
> No it's not about hiding anything, it's about how it is _represented_.
> Currently it is in user-made ad hoc directory structures, which can
> easily be abused by accident. I would be interested in seeing the tools
> go past that situation and implement some CM features more directly.
>
> - thomas beale
I see your point, but don't buy it. You argue, that the tool is bad,
because it does not force everyone to "do things the right way" (even
though the jury is still out on what "the right way" is). But this is a
generic tool, that can be easily (if not without some work) enhanced to so
exactly what you want. Or do whatever somebody else wants, in a different
way. On the other hand, if its structure was locked to your way of doing
things, than it would force all other "real developers" to do things just
one way. And maybe, by being more open, somebody will come up with an even
better way of doing things.
But beside that, if you can not make your users/developers conform to your
standards, than you have organizational problems, not software problems.
Cheers,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
Steve Williams wrote:
> Thomas Beale wrote:
>
>> I have used many CM systems, and have been thinking about whether
>> subversion supports the kinds of processes needed in real development,
>> particularly release management. I think that the basic advice of
>> using the trunk/tags/branches directories is ok, but does not go far
>> enough.
>
>
> That is, "real development" in your world of real development.
> Everyone's world of real development is slightly different. The above
> statement made it sound like Subversion is a toy versioning system not
> used in "real development".
Well I would say it is a good versioned file system implementation at
this stage - very good in fact. But it doesn't have any built in support
for branching or tagging, only lazy copying, which goes a go way to
making it work, but otherwise the facility is manual. This means it is
ad hoc, and no users or tools can make any assumptions about how
branches, tags etc work.
By "real" development I just meant any development that actually has a
wide user base, issue tracking lists, change requests to document
changes, and identified releases. I'm sure you will agree that it is
perfectly possible to build (great) software without all these things;
however such limited process usually corresponds to a small closed team
(e.g. an experimental academic development) or a sole developer.
>>
>> 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.
>
>
> Subversion does not impose any directory structure on you. Subversion
> supports whatever directory structure you want. If I wanted to, I could
> have a directory structure like this:
>
> - foo
> - BAR
> - pOoP
sure; and that's the problem/challenge at hand - imposing some standard
thinking on this. Consider it this way: if subversion's revisioning
really works (I mean: there are 0 bugs in the versioned representation
of files) - and as far as I can see, it is 99% there - then its
versioned representation of a directory tree is half-way to a defacto
standard representation of versioned hierarchical data. This hasn't
previously existed (well, CVS was there, but not very good at
representing changes other than to content of files; otherwise you had
closed things like VMS's versioning file system); if we went a bit
further and the community agreed a generic methodology about branching,
tagging and releasing, then that methodology could be introduced into
the tools as well. Such methodology is pretty well known in the world of
CM and is built into most commercial tools. It seems to me that
Subversion could be first off the block to both implement _and_
standardise it.
>
> and Subversion would still work as wonderfully as it does with the
> defacto standard of trunk, branches, tags. Uppercase, lowercase,
> naming. It is totally up to you.
>
> As for clients hiding those directories, you would have to customize one
> of the many available clients (they are open-source after all) since
> what you are trying to hide is your own idea of a "real development"
> directory structure.
No it's not about hiding anything, it's about how it is _represented_.
Currently it is in user-made ad hoc directory structures, which can
easily be abused by accident. I would be interested in seeing the tools
go past that situation and implement some CM features more directly.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
Steve Williams wrote:
> Thomas Beale wrote:
>
>> I have used many CM systems, and have been thinking about whether
>> subversion supports the kinds of processes needed in real development,
>> particularly release management. I think that the basic advice of
>> using the trunk/tags/branches directories is ok, but does not go far
>> enough.
>
>
> That is, "real development" in your world of real development.
> Everyone's world of real development is slightly different. The above
> statement made it sound like Subversion is a toy versioning system not
> used in "real development".
Well I would say it is a good versioned file system implementation at
this stage - very good in fact. But it doesn't have any built in support
for branching or tagging, only lazy copying, which goes a go way to
making it work, but otherwise the facility is manual. This means it is
ad hoc, and no users or tools can make any assumptions about how
branches, tags etc work.
By "real" development I just meant any development that actually has a
wide user base, issue tracking lists, change requests to document
changes, and identified releases. I'm sure you will agree that it is
perfectly possible to build (great) software without all these things;
however such limited process usually corresponds to a small closed team
(e.g. an experimental academic development) or a sole developer.
>>
>> 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.
>
>
> Subversion does not impose any directory structure on you. Subversion
> supports whatever directory structure you want. If I wanted to, I could
> have a directory structure like this:
>
> - foo
> - BAR
> - pOoP
sure; and that's the problem/challenge at hand - imposing some standard
thinking on this. Consider it this way: if subversion's revisioning
really works (I mean: there are 0 bugs in the versioned representation
of files) - and as far as I can see, it is 99% there - then its
versioned representation of a directory tree is half-way to a defacto
standard representation of versioned hierarchical data. This hasn't
previously existed (well, CVS was there, but not very good at
representing changes other than to content of files; otherwise you had
closed things like VMS's versioning file system); if we went a bit
further and the community agreed a generic methodology about branching,
tagging and releasing, then that methodology could be introduced into
the tools as well. Such methodology is pretty well known in the world of
CM and is built into most commercial tools. It seems to me that
Subversion could be first off the block to both implement _and_
standardise it.
>
> and Subversion would still work as wonderfully as it does with the
> defacto standard of trunk, branches, tags. Uppercase, lowercase,
> naming. It is totally up to you.
>
> As for clients hiding those directories, you would have to customize one
> of the many available clients (they are open-source after all) since
> what you are trying to hide is your own idea of a "real development"
> directory structure.
No it's not about hiding anything, it's about how it is _represented_.
Currently it is in user-made ad hoc directory structures, which can
easily be abused by accident. I would be interested in seeing the tools
go past that situation and implement some CM features more directly.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
Steve Williams wrote:
> Thomas Beale wrote:
>
>> I have used many CM systems, and have been thinking about whether
>> subversion supports the kinds of processes needed in real development,
>> particularly release management. I think that the basic advice of
>> using the trunk/tags/branches directories is ok, but does not go far
>> enough.
>
>
> That is, "real development" in your world of real development.
> Everyone's world of real development is slightly different. The above
> statement made it sound like Subversion is a toy versioning system not
> used in "real development".
Well I would say it is a good versioned file system implementation at
this stage - very good in fact. But it doesn't have any built in support
for branching or tagging, only lazy copying, which goes a go way to
making it work, but otherwise the facility is manual. This means it is
ad hoc, and no users or tools can make any assumptions about how
branches, tags etc work.
By "real" development I just meant any development that actually has a
wide user base, issue tracking lists, change requests to document
changes, and identified releases. I'm sure you will agree that it is
perfectly possible to build (great) software without all these things;
however such limited process usually corresponds to a small closed team
(e.g. an experimental academic development) or a sole developer.
>>
>> 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.
>
>
> Subversion does not impose any directory structure on you. Subversion
> supports whatever directory structure you want. If I wanted to, I could
> have a directory structure like this:
>
> - foo
> - BAR
> - pOoP
sure; and that's the problem/challenge at hand - imposing some standard
thinking on this. Consider it this way: if subversion's revisioning
really works (I mean: there are 0 bugs in the versioned representation
of files) - and as far as I can see, it is 99% there - then its
versioned representation of a directory tree is half-way to a defacto
standard representation of versioned hierarchical data. This hasn't
previously existed (well, CVS was there, but not very good at
representing changes other than to content of files; otherwise you had
closed things like VMS's versioning file system); if we went a bit
further and the community agreed a generic methodology about branching,
tagging and releasing, then that methodology could be introduced into
the tools as well. Such methodology is pretty well known in the world of
CM and is built into most commercial tools. It seems to me that
Subversion could be first off the block to both implement _and_
standardise it.
>
> and Subversion would still work as wonderfully as it does with the
> defacto standard of trunk, branches, tags. Uppercase, lowercase,
> naming. It is totally up to you.
>
> As for clients hiding those directories, you would have to customize one
> of the many available clients (they are open-source after all) since
> what you are trying to hide is your own idea of a "real development"
> directory structure.
No it's not about hiding anything, it's about how it is _represented_.
Currently it is in user-made ad hoc directory structures, which can
easily be abused by accident. I would be interested in seeing the tools
go past that situation and implement some CM features more directly.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Steve Williams <st...@kromestudios.com>.
Thomas Beale wrote:
> I have used many CM systems, and have been thinking about whether
> subversion supports the kinds of processes needed in real development,
> particularly release management. I think that the basic advice of using
> the trunk/tags/branches directories is ok, but does not go far enough.
That is, "real development" in your world of real development.
Everyone's world of real development is slightly different. The above
statement made it sound like Subversion is a toy versioning system not
used in "real development".
> We have so far defined the following in our repositories:
>
> - TRUNK: mainline current development;
> - BRANCHES: branch developments for new or alternative or test
> work;
> - TAGS: named baselines (no changes allowed)
> - RELEASES: release branches, i.e. branches corresponding to
> stable major points in the mainline (trunk) development,
> whose only further allowed changes are bugfixes.
>
> This corresponds more or less to the recommended way in Subversion of
> separating mainline development; the only difference is that in our
> project, upper-case directory names have been chosen to make the special
> status of these directories clear in a check-out structure, and the
> RELEASES directory has been added.
>
> "Releases" are really a kind of brnch but one where the allowed types of
> change is restricted to bugfixes. "Branches" are usually understood to
> be rela development changes.
>
> 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.
Subversion does not impose any directory structure on you. Subversion
supports whatever directory structure you want. If I wanted to, I could
have a directory structure like this:
- foo
- BAR
- pOoP
and Subversion would still work as wonderfully as it does with the
defacto standard of trunk, branches, tags. Uppercase, lowercase,
naming. It is totally up to you.
As for clients hiding those directories, you would have to customize one
of the many available clients (they are open-source after all) since
what you are trying to hide is your own idea of a "real development"
directory structure.
--
Sly
This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect.
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
David Weintraub wrote:
> On 7/28/05, Thomas Beale <th...@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
Re: early reflections on subversion methodology
Posted by Christopher Ness <ch...@nesser.org>.
On Fri, 2005-07-29 at 13:14 -0400, David Weintraub wrote:
<snip>
> 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.
FYI: This was a `svn mv` command I did. Which is a copy followed by a
delete. Notice the revision number in the "from" section of the add.
The --stop-on-copy flag to `svn log` will show you where a branch was
copied from.
[nesscg@summer sniffDB-scripts]$ svn log -v -r187 .
------------------------------------------------------------------------
r187 | nesscg | 2005-07-26 13:38:37 -0400 (Tue, 26 Jul 2005) | 1 line
Changed paths:
D /branches/nesscg/sniffDB
A /branches/sniffDB-scripts/db/layout
(from /branches/nesscg/sniffDB:186)
Moving layout diagram files to the main branch
------------------------------------------------------------------------
Cheers,
Chris
--
Wireless Group
McMaster University
summer
13:52:41 up 7 days, 23:45, 1 user, load average: 0.45, 0.33, 0.24
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: early reflections on subversion methodology
Posted by Thomas Beale <th...@deepthought.com.au>.
David Weintraub wrote:
> On 7/28/05, Thomas Beale <th...@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
Re: early reflections on subversion methodology
Posted by David Weintraub <qa...@gmail.com>.
On 7/28/05, Thomas Beale <th...@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.
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.
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.
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.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org