You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by kf...@collab.net on 2004/10/13 16:22:05 UTC
Re: CVS/SVN comparison
Andrew n marshall <am...@ISI.EDU> writes:
> Searching the web, I came up with this:
> http://www.pushok.com/soft_svn_vscvs.php
> but it is undated. Are the comments provided still accurate?
The statements of fact there are mostly accurate (some of the opinions
I disagree with, but that's okay). There are a couple of mistakes,
though. I've CC'd PushOk's webmaster here, in case they want to make
corrections.
First, the paragraph about SVN tagging:
"The SVN developers assert with pride that they have got rid of 3
measurements by working with tags and branches. In practice it
means that they have substituted both concepts for a capability of
copying file(s) or directories within the repository with saving
the history of changes. That is, both tag creation and branch
creation are substituted for copying within the repository. From
the SVN developers' viewpoint, this is very elegant decision, which
simplifies one's life. However, we think that there is nothing to
be proud of. As for branches, everything is not so bad, now
branches are nothing but separate folders in the repository, which
earlier have had some interconnection. As for tags, everything is
much worse. Now you cannot tag a code, this function is simply
missing. Certainly, to some extent this is compensated by universal
numbering of files in SVN, that is, the whole repository gets the
version number, but not each separate file. However, we suppose you
will not deny that it is not very convenient to store a four-digit
number instead of a symbolic tag."
The assertion "you cannot tag a code, the function is simply missing"
is false. I don't know why they think you can't tag code. In
Subversion, as in CVS, you can tag a working copy to get a repository
structure that represents the exact mixed-version state of that
working copy. Or you can tag a state that's already in the
repository, again just as with CVS.
I also don't know what the last sentence means. Subversion tags are
not four-digit numbers, they are UTF8 strings. Any CVS tag name can
use the same name in Subversion.
While Subversion's *representation* of tags is slightly different,
Subversion tags do basically the same things as CVS's. Maybe I'm just
misunderstanding what PushOk is trying to say above, but the most
natural interpretations do seem to be false.
The other mistake is quite understandable, as the FSFS (non-Berkeley)
repository was probably not available at the time they wrote this:
"The basis of SVN is a relational database (BerkleyDB). On one
hand, this settles many problems (for example, concurrent access
through the file share) and enables new functionalities (for
example, transactions at operations performance). However, on the
other hand, data storage now is not transparent, or at least is not
available for user interference. That is why the utilities for
'curing' and 'recovering' of the repository (database) are
provided."
Note also that BerkeleyDB is not a "relational database". It's a data
storage/retrieval mechanism, without relational capabilities.
Anyway, BerkeleyDB is now one of two options for repository storage.
I'd also like to point out that the locking/reserved-checkouts
discussion now under way will soon give us one of the missing features
PushOk's page talks about the most: CVS's edit/watch functionality.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by Steve Greenland <st...@lsli.com>.
On Fri, Oct 22, 2004 at 04:23:38PM +0100, Anthony Metcalf wrote:
> Then what if someone gets the "release-co-ordinator's" password?
What if someone gets the root password to the server?
>
> I tend to agree that subversion doesn't support tags. It supports
> copying, and with a little effort you can make it look like it
> supports tags. It does not support, out of the box, a cammand like
>
> svn tag or svn tag -rN,
>
> which then cannot be altered from within subversion, by anyone.
>
> At least, in my opinion, thats what "tags" mean.
By that definition, CVS doesn't have tags. As far as I know, most VC
systems allow tags to be modified, with appropriate privileges and/or
invocation options.
None the less, I'll throw in a vote for some sort of "revision alias",
mapping r1234 -> some_name. Yes, it can't represent mix versions, but
for %95-100% of what I use tags for, it would be sufficient, and somehow
seems more convenient that having separate directories. Not that I'd
want to give up copies, though, as they are certainly a useful tool,
too.
Steve
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
-- (Stolen from the net)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by Peter Williams <pe...@aurema.com>.
Anthony Metcalf wrote:
> On Fri, 22 Oct 2004 11:11:24 -0400
> "David F. Newman" <dn...@epnet.com> wrote:
>
>
>>> With your approach there NO difference between TAG and BRANCH. All
>>>that is the COPY. One copy, called TAG we _promise_ do not change. And
>>>that's why it is a TAG. But nothing can prevent me from modifying this
>>>COPY. So, some "bad" developer CAN change the TAG.
>>
>>One can force a read-only policy on tags by making the /tags directory
>>read-only to everyone except the release coordinator using
>>mod_authz_svn. Then a bad developer can't change tags.
>
>
> Then what if someone gets the "release-co-ordinator's" password?
>
> I tend to agree that subversion doesn't support tags. It supports copying, and with a little effort you can make it look like it supports tags. It does not support, out of the box, a cammand like
>
> svn tag or svn tag -rN, which then cannot be altered from within subversion, by anyone.
>
> At least, in my opinion, thats what "tags" mean.
>
> <disclaimers>
> 1) I know all this in effect is, is putting a specific name on a -rN. Isn't that the idea?
> 2) Subversion is the first version control system I've ever used. I don't know how it works in other systems, I am simply saying what I think of as tagging for a release, from the point of view of what I will want to do in the future with things in my repo's.
> </disclaimers>
I think that a fair summary of any CVS/SVN comparison is that (in spite
of its claims) SVN is NOT a replacement for CVS. It is however a set of
primitive operations on top of which a CVS replacement could be built.
Peter
--
Dr Peter Williams, Chief Scientist peterw@aurema.com
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Fri, 22 Oct 2004 17:01:22 +0100
Jeremy Pereira <je...@ntlworld.com> wrote:
> Well then cvs doesn't support tags properly either (use cvs tag -F).
> You can move cvs tags around. Not only that, when you move a cvs tag
> there is no audit information created AFAIK.
I never said it did, I wouldn't know, I've never used cvs expect to grab some souce to compile.
Re: CVS/SVN comparison
Posted by Jeremy Pereira <je...@ntlworld.com>.
On Oct 22, 2004, at 16:23, Anthony Metcalf wrote:
> On Fri, 22 Oct 2004 11:11:24 -0400
> "David F. Newman" <dn...@epnet.com> wrote:
>
>>> With your approach there NO difference between TAG and BRANCH. All
>>> that is the COPY. One copy, called TAG we _promise_ do not change.
>>> And
>>> that's why it is a TAG. But nothing can prevent me from modifying
>>> this
>>> COPY. So, some "bad" developer CAN change the TAG.
>>
>> One can force a read-only policy on tags by making the /tags directory
>> read-only to everyone except the release coordinator using
>> mod_authz_svn. Then a bad developer can't change tags.
>
> Then what if someone gets the "release-co-ordinator's" password?
>
> I tend to agree that subversion doesn't support tags. It supports
> copying, and with a little effort you can make it look like it
> supports tags. It does not support, out of the box, a cammand like
>
> svn tag or svn tag -rN, which then cannot be altered from within
> subversion, by anyone.
Well then cvs doesn't support tags properly either (use cvs tag -F).
You can move cvs tags around. Not only that, when you move a cvs tag
there is no audit information created AFAIK.
>
> At least, in my opinion, thats what "tags" mean.
>
> <disclaimers>
> 1) I know all this in effect is, is putting a specific name on a -rN.
> Isn't that the idea?
> 2) Subversion is the first version control system I've ever used. I
> don't know how it works in other systems, I am simply saying what I
> think of as tagging for a release, from the point of view of what I
> will want to do in the future with things in my repo's.
> </disclaimers>
>
--
Jeremy Pereira
http://www.jeremyp.net
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by Anthony Metcalf <an...@anferny.ath.cx>.
On Fri, 22 Oct 2004 11:11:24 -0400
"David F. Newman" <dn...@epnet.com> wrote:
> > With your approach there NO difference between TAG and BRANCH. All
> > that is the COPY. One copy, called TAG we _promise_ do not change. And
> > that's why it is a TAG. But nothing can prevent me from modifying this
> > COPY. So, some "bad" developer CAN change the TAG.
>
> One can force a read-only policy on tags by making the /tags directory
> read-only to everyone except the release coordinator using
> mod_authz_svn. Then a bad developer can't change tags.
Then what if someone gets the "release-co-ordinator's" password?
I tend to agree that subversion doesn't support tags. It supports copying, and with a little effort you can make it look like it supports tags. It does not support, out of the box, a cammand like
svn tag or svn tag -rN, which then cannot be altered from within subversion, by anyone.
At least, in my opinion, thats what "tags" mean.
<disclaimers>
1) I know all this in effect is, is putting a specific name on a -rN. Isn't that the idea?
2) Subversion is the first version control system I've ever used. I don't know how it works in other systems, I am simply saying what I think of as tagging for a release, from the point of view of what I will want to do in the future with things in my repo's.
</disclaimers>
Re: CVS/SVN comparison
Posted by Scott Palmer <sc...@2connected.org>.
On Oct 22, 2004, at 3:43 PM, Mark Phippard wrote:
> Scott Palmer <sc...@2connected.org> wrote on 10/22/2004 03:18:53
> PM:
>> I'm not suggesting anything is hard about it. I'm simply saying that
>> it does not result in a (reasonably) immutable copy.. which is *my*
>> definition of a tag, and there are obviously many others that have an
>> equivalent definition of what a tag should be.
>
> I am not aware of any version control tool that does not provide some
> way
> to alter tags after the fact. Therefore the immutable argument is a
> bit
> over stated. While some of the higher end commercial tools track
> changes
> made to tags, most of the common ones like CVS, PVCS and VSS do not.
I inserted the word "reasonably" for a reason. VSS uses "labels", you
can not get a labeled version, make a change and check it in and then
have the label refer to the new code instead of the old code, which is
precisely what will happen with subversion. Subversion "tags" are
fragile.
> Personally, I do not want immutable tags --
Understood. It all depends on the workflow you use and personal taste.
Subversion is touted as being flexible - but it is inflexible in the
sense that it does not offer much assistance to supporting an immutable
marker. The commit-hook idea seems to be the trick to making this
work, but it is essentially a workaround that must be applied on top of
a basic subversion install. That being said, perhaps it is not so bad
of a solution - I have yet to try it.
> What I think is the main issue is that it would be so easy for someone
> to commit
> changes to a tag by accident, without the tool doing anything to help.
That is exactly what I am concerned about. A naming convention in the
repository is too loose. Specially when you may not be aware of what
location in the repository your working copy is associated with. It is
easy to find out, but it is also easy no to check. "svn commit" doesn't
care, nor does it tell you where it committed to, so you may not find
out about a mistake that needs to be rolled back.
> Currently, this can be solved by using Apache and mod_authz_svn or by
> using hook scripts. I know that the developers have talked a lot about
> adding ACL's into the repository layer itself and I think this feature
> will likely come in a reasonable time frame. When that feature
> exists, I
> think it will be relatively easy to define permission's in the
> repository
> itself that create the "immutability" feature that some desire. Until
> then, you have to use hooks. I personally see no more problem using
> hooks
> for something like this, then I do with using hooks to send commit
> emails.
Sure. I hope it doesn't seem like I'm whining about this :) I'm just
trying to provide feedback so that when/if the feature is designed and
developed that this discussion will be here to draw upon for ideas.
> BTW, if you do the latter a nice benefit is you would be emailed if
> someone committed to a tags folder. So, in the event of an accident,
> the
> change can be reverted.
Good idea. though on windows all this stuff is a bit more of a pain.
> I think a nice idea might be to setup a "repository" of sample hooks
> that
> implement these ideas. There are some in the svn repository itself,
> but I
> am thinking something more "web-based" with accompanying documentation
> etc.. Kind of a Subversion "hooks" community. Maybe this would be a
> good
> Wiki-style app?
A great idea!
> It would also be nice if some of the hooks were then
> implemented in different languages so we did not all have to become
> Perl
> experts to use them.
I too prefer my code un-obfuscated.
> Anyway, this issue has been beaten to death in the last couple of
> months,
> so that is all I have to say.
yeah, I'm shutting up now too - unless I can't get the commit-hook
thing to work :)
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by Mark Phippard <Ma...@softlanding.com>.
Scott Palmer <sc...@2connected.org> wrote on 10/22/2004 03:18:53
PM:
>
> On Oct 22, 2004, at 2:31 PM, John Szakmeister wrote:
>
> > On Friday 22 October 2004 13:57, Scott Palmer wrote:
> >
> >> For ease of use the svn copy command could have a flag to say I'm
> >> making a "tag" copy, and the "tag" property would automatically be
set
> >> on the copy.
> >
> > What's so hard about svn cp http://.../trunk http://.../tags/1.0?
>
> I'm not suggesting anything is hard about it. I'm simply saying that
> it does not result in a (reasonably) immutable copy.. which is *my*
> definition of a tag, and there are obviously many others that have an
> equivalent definition of what a tag should be.
I am not aware of any version control tool that does not provide some way
to alter tags after the fact. Therefore the immutable argument is a bit
over stated. While some of the higher end commercial tools track changes
made to tags, most of the common ones like CVS, PVCS and VSS do not.
Therefore, if anything there are some advantages to Subversion in that any
changes are tracked, and since you have the global revision number, can be
reverted.
Personally, I do not want immutable tags -- I like being able to make
minor updates. As an example, if you look at the tags for Subversion
itself, when they make a tag it is usually followed by at least 1 commit
to svn_version.h to update the release information for the tarball. That
being said, I can understand why some people want this feature. What I
think is the main issue is that it would be so easy for someone to commit
changes to a tag by accident, without the tool doing anything to help.
Currently, this can be solved by using Apache and mod_authz_svn or by
using hook scripts. I know that the developers have talked a lot about
adding ACL's into the repository layer itself and I think this feature
will likely come in a reasonable time frame. When that feature exists, I
think it will be relatively easy to define permission's in the repository
itself that create the "immutability" feature that some desire. Until
then, you have to use hooks. I personally see no more problem using hooks
for something like this, then I do with using hooks to send commit emails.
BTW, if you do the latter a nice benefit is you would be emailed if
someone committed to a tags folder. So, in the event of an accident, the
change can be reverted.
I think a nice idea might be to setup a "repository" of sample hooks that
implement these ideas. There are some in the svn repository itself, but I
am thinking something more "web-based" with accompanying documentation
etc.. Kind of a Subversion "hooks" community. Maybe this would be a good
Wiki-style app? It would also be nice if some of the hooks were then
implemented in different languages so we did not all have to become Perl
experts to use them.
Anyway, this issue has been beaten to death in the last couple of months,
so that is all I have to say.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by Scott Palmer <sc...@2connected.org>.
On Oct 22, 2004, at 2:31 PM, John Szakmeister wrote:
> On Friday 22 October 2004 13:57, Scott Palmer wrote:
>
>> For ease of use the svn copy command could have a flag to say I'm
>> making a "tag" copy, and the "tag" property would automatically be set
>> on the copy.
>
> What's so hard about svn cp http://.../trunk http://.../tags/1.0?
I'm not suggesting anything is hard about it. I'm simply saying that
it does not result in a (reasonably) immutable copy.. which is *my*
definition of a tag, and there are obviously many others that have an
equivalent definition of what a tag should be.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by John Szakmeister <jo...@szakmeister.net>.
On Friday 22 October 2004 13:57, Scott Palmer wrote:
> On Oct 22, 2004, at 1:41 PM, John Szakmeister wrote:
> > David F. Newman wrote:
> >> On Fri, 2004-10-22 at 06:10, pushok wrote:
> >>> With your approach there NO difference between TAG and BRANCH.
> >>> All that is the COPY. One copy, called TAG we _promise_ do not
> >>> change. And
> >>> that's why it is a TAG. But nothing can prevent me from modifying
> >>> this
> >>> COPY. So, some "bad" developer CAN change the TAG.
> >>
> >> One can force a read-only policy on tags by making the /tags
> >> directory read-only to everyone except the release coordinator using
> >> mod_authz_svn. Then a bad developer can't change tags.
> >
> > This can also be forced by using a pre-commit hook script. I made
> > one that allows you to create a tag, but you can't commit any changes
> > under it.
>
> In other words, you had to write your own code to work around the lack
> of this feature in subversion. :)
On the contrary, Subversion is so flexible, that I can make it do what I
want with hook scripts. :-)
> I would think that subversion could support some sort of standard
> property that indicated "this copy is a tag" and then it could enforce
> the immutability of that copy in some way.
Perhaps one day. You aren't the first person to mention having such a
thing. Personally, better branch support (seeing where files have been
copied to), and merge tracking are of much more concern to me.
> For ease of use the svn copy command could have a flag to say I'm
> making a "tag" copy, and the "tag" property would automatically be set
> on the copy.
What's so hard about svn cp http://.../trunk http://.../tags/1.0?
I know what you're getting at, you'd like to see built-in support for
tags. But I see it from a different view point, the scripts allow me to
set up my own policy for tags. I'm not restricted to what the developers
think is a 'tag'.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by Scott Palmer <sc...@2connected.org>.
On Oct 22, 2004, at 2:19 PM, Keven Ring wrote:
> Scott Palmer wrote:
>> In other words, you had to write your own code to work around the
>> lack of this feature in subversion. :)
>
> IIRC, CVS does not have *any* ACL built in (I know that there are
> pre-commit "hooks" for CVS, but someone had to write their own code).
I don't care about CVS. I have never used it and never will. And I'm
not really talking about access control as much as I want an easy
common way to make immutable copies (what I will call "tags")
regardless of how I choose to access the repository.
> You are unwilling to accept what Subversion calls a "tag" as a
> "tag", because it doesn't fit your definition.
Exactly. In other words, where is the flexibility you speak of below
if it can't fit my definition :) ?
> There are other ways to create a "tag" without copying that ensure
> immutability (eg, via properties), but then there are other issues.
> The bottom line is that "tags" are an idea, and subversion provides a
> recommended convention for supporting that idea. IMHO, this is better
> than enforcing a single convention, and forcing everyone to fit to
> that model, like it or not.
I agree.. the problem is it does not support my model of what a tag is
without extra work.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by Keven Ring <ke...@mitre.org>.
Scott Palmer wrote:
> On Oct 22, 2004, at 1:41 PM, John Szakmeister wrote:
>
>> David F. Newman wrote:
>>
>>> On Fri, 2004-10-22 at 06:10, pushok wrote:
>>>
>>>> With your approach there NO difference between TAG and BRANCH. All
>>>> that is the COPY. One copy, called TAG we _promise_ do not change. And
>>>> that's why it is a TAG. But nothing can prevent me from modifying this
>>>> COPY. So, some "bad" developer CAN change the TAG.
>>>
>>>
>>> One can force a read-only policy on tags by making the /tags directory
>>> read-only to everyone except the release coordinator using
>>> mod_authz_svn. Then a bad developer can't change tags.
>>
>>
>> This can also be forced by using a pre-commit hook script. I made one
>> that allows you to create a tag, but you can't commit any changes
>> under it.
>
>
> In other words, you had to write your own code to work around the lack
> of this feature in subversion. :)
IIRC, CVS does not have *any* ACL built in (I know that there are
pre-commit "hooks" for CVS, but someone had to write their own code).
You are unwilling to accept what Subversion calls a "tag" as a "tag",
because it doesn't fit your definition.
There are other ways to create a "tag" without copying that ensure
immutability (eg, via properties), but then there are other issues. The
bottom line is that "tags" are an idea, and subversion provides a
recommended convention for supporting that idea. IMHO, this is better
than enforcing a single convention, and forcing everyone to fit to that
model, like it or not.
>
> I would think that subversion could support some sort of standard
> property that indicated "this copy is a tag" and then it could enforce
> the immutability of that copy in some way.
I believe that there has been a lot of discussion about "immutable
tags", primarily on the dev@ list.
>
>
> For ease of use the svn copy command could have a flag to say I'm
> making a "tag" copy, and the "tag" property would automatically be set
> on the copy.
I believe that such a request should go to the dev@ list, since users@
doesn't really vote on what should be changed.
--
Keven Ring | "Oh no, Not Again..."
The MITRE Corporation | Bowl of Petunias -
7515 Colshire Drive | The Hitchhikers Guide to the Galaxy
McLean VA 22102-7508 |
PH: (703)883-7026 |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by Scott Palmer <sc...@2connected.org>.
On Oct 22, 2004, at 1:41 PM, John Szakmeister wrote:
> David F. Newman wrote:
>> On Fri, 2004-10-22 at 06:10, pushok wrote:
>>
>>> With your approach there NO difference between TAG and BRANCH. All
>>> that is the COPY. One copy, called TAG we _promise_ do not change.
>>> And
>>> that's why it is a TAG. But nothing can prevent me from modifying
>>> this
>>> COPY. So, some "bad" developer CAN change the TAG.
>>
>> One can force a read-only policy on tags by making the /tags directory
>> read-only to everyone except the release coordinator using
>> mod_authz_svn. Then a bad developer can't change tags.
>
> This can also be forced by using a pre-commit hook script. I made one
> that allows you to create a tag, but you can't commit any changes
> under it.
In other words, you had to write your own code to work around the lack
of this feature in subversion. :)
I would think that subversion could support some sort of standard
property that indicated "this copy is a tag" and then it could enforce
the immutability of that copy in some way.
For ease of use the svn copy command could have a flag to say I'm
making a "tag" copy, and the "tag" property would automatically be set
on the copy.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS/SVN comparison
Posted by John Szakmeister <jo...@szakmeister.net>.
David F. Newman wrote:
> On Fri, 2004-10-22 at 06:10, pushok wrote:
>
>> With your approach there NO difference between TAG and BRANCH. All
>>that is the COPY. One copy, called TAG we _promise_ do not change. And
>>that's why it is a TAG. But nothing can prevent me from modifying this
>>COPY. So, some "bad" developer CAN change the TAG.
>
>
> One can force a read-only policy on tags by making the /tags directory
> read-only to everyone except the release coordinator using
> mod_authz_svn. Then a bad developer can't change tags.
This can also be forced by using a pre-commit hook script. I made one
that allows you to create a tag, but you can't commit any changes under it.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: CVS/SVN comparison
Posted by "David F. Newman" <dn...@epnet.com>.
On Fri, 2004-10-22 at 06:10, pushok wrote:
> With your approach there NO difference between TAG and BRANCH. All
> that is the COPY. One copy, called TAG we _promise_ do not change. And
> that's why it is a TAG. But nothing can prevent me from modifying this
> COPY. So, some "bad" developer CAN change the TAG.
One can force a read-only policy on tags by making the /tags directory
read-only to everyone except the release coordinator using
mod_authz_svn. Then a bad developer can't change tags.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[4]: CVS/SVN comparison
Posted by pushok <co...@pushok.com>.
Hello kfogel,
kcn> CVS supports renames? On *folders*?? Not according to
kcn> https://www.cvshome.org/docs/manual/cvs-1.12.9/cvs_7.html#SEC70.
Sorry, I mean CVS NT (which unix port also exist as you can know).
--
Best regards,
pushok mailto:contact@pushok.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: CVS/SVN comparison
Posted by kf...@collab.net.
pushok <co...@pushok.com> writes:
> Hello kfogel,
> Few comments about your comments:
> 1. TAGS AND BRANCHES
> Again, tags and branches replaced in SVN with copy in repository.
> This is similar like all (I think) backup their code before they know
> about SCM. For example, I, when was a student, just copy each day
> entire source tree of my diploma. You make the same but in repository.
> With your approach there NO difference between TAG and BRANCH. All
> that is the COPY. One copy, called TAG we _promise_ do not change. And
> that's why it is a TAG. But nothing can prevent me from modifying this
> COPY. So, some "bad" developer CAN change the TAG. How this looks for
> you? That's why we claim that you system not have the TAGS.
> Just for me, TAG, is only TAG - some symbolic label that describes
> _some_ state of source code (entire rep, or some of its folder, or
> some file). In SVN such state is _repository revision_. That's why I
> make analog between TAG and your REP REVISION.
If the intended audience for your document were just you, all this
would make sense. However, since most Subversion apparently think
they are getting tag functionality in the way we recommend, your claim
that "the function is simply missing" is likely to mislead most
readers.
It would be better to describe what's actually going on, and let
people judge for themselves, I think.
> And finally, if you will allow to "mark" or "associate" some
> symbolic name with your REVISION for me it will be the TAG. In other
> words I only just one mark r12345 as "rev_1_1".
I agree that would be a useful feature, but it would offer *less*
functionality than CVS or SVN tags currently do, since it could only
tag one revision tree, not a mixed set of paths/revisions.
> 2. No comment about new fs_fs. Any way we will put the information for
> which version of CVS and SVN this comparison is valid.
Thanks.
> Since for example right now CVS support client side renames in
> repository both files and folders :)....
CVS supports renames? On *folders*?? Not according to
https://www.cvshome.org/docs/manual/cvs-1.12.9/cvs_7.html#SEC70.
CVS has some commands which can be used to achieve something close to
renaming, but with odd side effects (such as the old directory
continuing be present if -P is not passed to checkout, etc).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[2]: CVS/SVN comparison
Posted by pushok <co...@pushok.com>.
Hello kfogel,
Few comments about your comments:
1. TAGS AND BRANCHES
Again, tags and branches replaced in SVN with copy in repository.
This is similar like all (I think) backup their code before they know
about SCM. For example, I, when was a student, just copy each day
entire source tree of my diploma. You make the same but in repository.
With your approach there NO difference between TAG and BRANCH. All
that is the COPY. One copy, called TAG we _promise_ do not change. And
that's why it is a TAG. But nothing can prevent me from modifying this
COPY. So, some "bad" developer CAN change the TAG. How this looks for
you? That's why we claim that you system not have the TAGS.
Just for me, TAG, is only TAG - some symbolic label that describes
_some_ state of source code (entire rep, or some of its folder, or
some file). In SVN such state is _repository revision_. That's why I
make analog between TAG and your REP REVISION.
And finally, if you will allow to "mark" or "associate" some
symbolic name with your REVISION for me it will be the TAG. In other
words I only just one mark r12345 as "rev_1_1".
Why this needed? Very simple. I just want to get difference between
my current version and version 1.0 (for example). Right now I need to
compare file "_svnserver/tags/version1_0/myfile.c" with
"_svnserver/myfile.c" or "r12000" with "r12356". The first is very
complex (why to type full path, only because I not remember revision
of version1-0). Other (user revision) is simple, but I NOT remember
numeric revision of "version1_0". That's why, I think, symbolic labels
for numeric revisions (TAGS are needed).
2. No comment about new fs_fs. Any way we will put the information for
which version of CVS and SVN this comparison is valid. Since for
example right now CVS support client side renames in repository both
files and folders :)....
Wednesday, October 13, 2004, 8:22:05 PM, you wrote:
kcn> Andrew n marshall <am...@ISI.EDU> writes:
>> Searching the web, I came up with this:
>> http://www.pushok.com/soft_svn_vscvs.php
>> but it is undated. Are the comments provided still accurate?
kcn> The statements of fact there are mostly accurate (some of the opinions
kcn> I disagree with, but that's okay). There are a couple of mistakes,
kcn> though. I've CC'd PushOk's webmaster here, in case they want to make
kcn> corrections.
kcn> First, the paragraph about SVN tagging:
kcn> "The SVN developers assert with pride that they have got rid of 3
kcn> measurements by working with tags and branches. In practice it
kcn> means that they have substituted both concepts for a capability of
kcn> copying file(s) or directories within the repository with saving
kcn> the history of changes. That is, both tag creation and branch
kcn> creation are substituted for copying within the repository. From
kcn> the SVN developers' viewpoint, this is very elegant decision, which
kcn> simplifies one's life. However, we think that there is nothing to
kcn> be proud of. As for branches, everything is not so bad, now
kcn> branches are nothing but separate folders in the repository, which
kcn> earlier have had some interconnection. As for tags, everything is
kcn> much worse. Now you cannot tag a code, this function is simply
kcn> missing. Certainly, to some extent this is compensated by universal
kcn> numbering of files in SVN, that is, the whole repository gets the
kcn> version number, but not each separate file. However, we suppose you
kcn> will not deny that it is not very convenient to store a four-digit
kcn> number instead of a symbolic tag."
kcn> The assertion "you cannot tag a code, the function is simply missing"
kcn> is false. I don't know why they think you can't tag code. In
kcn> Subversion, as in CVS, you can tag a working copy to get a repository
kcn> structure that represents the exact mixed-version state of that
kcn> working copy. Or you can tag a state that's already in the
kcn> repository, again just as with CVS.
kcn> I also don't know what the last sentence means. Subversion tags are
kcn> not four-digit numbers, they are UTF8 strings. Any CVS tag name can
kcn> use the same name in Subversion.
kcn> While Subversion's *representation* of tags is slightly different,
kcn> Subversion tags do basically the same things as CVS's. Maybe I'm just
kcn> misunderstanding what PushOk is trying to say above, but the most
kcn> natural interpretations do seem to be false.
kcn> The other mistake is quite understandable, as the FSFS (non-Berkeley)
kcn> repository was probably not available at the time they wrote this:
kcn> "The basis of SVN is a relational database (BerkleyDB). On one
kcn> hand, this settles many problems (for example, concurrent access
kcn> through the file share) and enables new functionalities (for
kcn> example, transactions at operations performance). However, on the
kcn> other hand, data storage now is not transparent, or at least is not
kcn> available for user interference. That is why the utilities for
kcn> 'curing' and 'recovering' of the repository (database) are
kcn> provided."
kcn> Note also that BerkeleyDB is not a "relational database". It's a data
kcn> storage/retrieval mechanism, without relational capabilities.
kcn> Anyway, BerkeleyDB is now one of two options for repository storage.
kcn> I'd also like to point out that the locking/reserved-checkouts
kcn> discussion now under way will soon give us one of the missing features
kcn> PushOk's page talks about the most: CVS's edit/watch functionality.
kcn> -Karl
--
Best regards,
pushok mailto:contact@pushok.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: CVS/SVN comparison
Posted by kf...@collab.net.
pushok <co...@pushok.com> writes:
> Hello kfogel,
> ANOTHER ISSUE, _PLEASE_ FIND 1 min to read this letter....
No need to beg, I'm reading the mails :-).
> I wonder how we can submit patches for you SVN. More exactly, I claim
> "there is bad thing in your code for read-only flag on windows".
> Anybody (from 20 developers of SVN) interested to know about this?
> I already submit this patch to your dev list, but all just ignore
> it (nice). So the problems we have:
That sometimes happens, it's nothing personal. You can make the patch
more attractive by including a log message. See the guidelines in
http://svn.collab.net/repos/svn/trunk/HACKING about submitting patches
and writing log messages, thanks.
> 1. SVN shows error when tries to update read-only files.
> 2. Our plug-in wants to have not modified files read-only, since that
> expect behavior.
> What we found in SVN code and what we make:
> 1. We found that you already have problems with that behavior (update
> of read-only files). And implement dummy and bad patch for this -
> function "svn_wc__prep_file_for_replacement". It makes nothing for all
> platform and only for Windows remove the read-only flag. So, in
> critical places you put code like this:
> SVN_ERR (svn_wc__prep_file_for_replacement (basef, TRUE, pool));
> SVN_ERR (svn_io_file_rename (tmpf, basef, pool));
> SVN_ERR (svn_io_set_file_read_only (basef, FALSE, pool));
> LOOKS STRANGE, RIGHT?
> So, we just follow the linux rules, that allows to rename file if it
> is read-only and make patch for your rename function. This way all
> works now fine:
> * not need to have the svn_wc__prep_file_for_replacement, it is
> just delete
> * the code above now looks like
> SVN_ERR (svn_io_file_rename (tmpf, basef, pool));
> * readonly correctly handled on widnows. SVN do not show error
> updating it and basic rule is: if file readonly it will remain
> readonly after update, if writable, it will remain writable.
I think there were some reasons we did things this way, but I can't
remember what they were now. Can you try asking on the dev@ list in a
new thread?
> 2. We also make patch (few small things) that allow SVN mimics CVS
> "Checkout file readonly". I.e. pull new files as readonly, make them
> readonly after commit. This way not edited files are readonly which
> is very good for IDE. All changed about that are paced in "#ifdef
> SVN_CLIENT_CHECKOUT_READONLY" blocks. I not suggest to make this, if
> you not want, this is extra functionality. However taking into account
> your new goal for SVN 1.2 this may be useful.
A separate patch for this would be better than mixing it in with the
other changes.
> I attach patch file for SVN 1.1 that makes all that I describe. Please
> _ANYBODY_ response to this.
Post to dev@ list with "[PATCH]" in the subject. Post a separate
email for each logically separate change. Include a log message for
each patch.
I don't know when you posted the patches last time, but we have a
patch manager now who does a very thorough job of making sure patches
don't get lost.
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[2]: CVS/SVN comparison
Posted by pushok <co...@pushok.com>.
Hello kfogel,
ANOTHER ISSUE, _PLEASE_ FIND 1 min to read this letter....
I wonder how we can submit patches for you SVN. More exactly, I claim
"there is bad thing in your code for read-only flag on windows".
Anybody (from 20 developers of SVN) interested to know about this?
I already submit this patch to your dev list, but all just ignore
it (nice). So the problems we have:
1. SVN shows error when tries to update read-only files.
2. Our plug-in wants to have not modified files read-only, since that
expect behavior.
What we found in SVN code and what we make:
1. We found that you already have problems with that behavior (update
of read-only files). And implement dummy and bad patch for this -
function "svn_wc__prep_file_for_replacement". It makes nothing for all
platform and only for Windows remove the read-only flag. So, in
critical places you put code like this:
SVN_ERR (svn_wc__prep_file_for_replacement (basef, TRUE, pool));
SVN_ERR (svn_io_file_rename (tmpf, basef, pool));
SVN_ERR (svn_io_set_file_read_only (basef, FALSE, pool));
LOOKS STRANGE, RIGHT?
So, we just follow the linux rules, that allows to rename file if it
is read-only and make patch for your rename function. This way all
works now fine:
* not need to have the svn_wc__prep_file_for_replacement, it is
just delete
* the code above now looks like
SVN_ERR (svn_io_file_rename (tmpf, basef, pool));
* readonly correctly handled on widnows. SVN do not show error
updating it and basic rule is: if file readonly it will remain
readonly after update, if writable, it will remain writable.
2. We also make patch (few small things) that allow SVN mimics CVS
"Checkout file readonly". I.e. pull new files as readonly, make them
readonly after commit. This way not edited files are readonly which
is very good for IDE. All changed about that are paced in "#ifdef
SVN_CLIENT_CHECKOUT_READONLY" blocks. I not suggest to make this, if
you not want, this is extra functionality. However taking into account
your new goal for SVN 1.2 this may be useful.
I attach patch file for SVN 1.1 that makes all that I describe. Please
_ANYBODY_ response to this.
Wednesday, October 13, 2004, 8:22:05 PM, you wrote:
kcn> Andrew n marshall <am...@ISI.EDU> writes:
>> Searching the web, I came up with this:
>> http://www.pushok.com/soft_svn_vscvs.php
>> but it is undated. Are the comments provided still accurate?
kcn> The statements of fact there are mostly accurate (some of the opinions
kcn> I disagree with, but that's okay). There are a couple of mistakes,
kcn> though. I've CC'd PushOk's webmaster here, in case they want to make
kcn> corrections.
kcn> First, the paragraph about SVN tagging:
kcn> "The SVN developers assert with pride that they have got rid of 3
kcn> measurements by working with tags and branches. In practice it
kcn> means that they have substituted both concepts for a capability of
kcn> copying file(s) or directories within the repository with saving
kcn> the history of changes. That is, both tag creation and branch
kcn> creation are substituted for copying within the repository. From
kcn> the SVN developers' viewpoint, this is very elegant decision, which
kcn> simplifies one's life. However, we think that there is nothing to
kcn> be proud of. As for branches, everything is not so bad, now
kcn> branches are nothing but separate folders in the repository, which
kcn> earlier have had some interconnection. As for tags, everything is
kcn> much worse. Now you cannot tag a code, this function is simply
kcn> missing. Certainly, to some extent this is compensated by universal
kcn> numbering of files in SVN, that is, the whole repository gets the
kcn> version number, but not each separate file. However, we suppose you
kcn> will not deny that it is not very convenient to store a four-digit
kcn> number instead of a symbolic tag."
kcn> The assertion "you cannot tag a code, the function is simply missing"
kcn> is false. I don't know why they think you can't tag code. In
kcn> Subversion, as in CVS, you can tag a working copy to get a repository
kcn> structure that represents the exact mixed-version state of that
kcn> working copy. Or you can tag a state that's already in the
kcn> repository, again just as with CVS.
kcn> I also don't know what the last sentence means. Subversion tags are
kcn> not four-digit numbers, they are UTF8 strings. Any CVS tag name can
kcn> use the same name in Subversion.
kcn> While Subversion's *representation* of tags is slightly different,
kcn> Subversion tags do basically the same things as CVS's. Maybe I'm just
kcn> misunderstanding what PushOk is trying to say above, but the most
kcn> natural interpretations do seem to be false.
kcn> The other mistake is quite understandable, as the FSFS (non-Berkeley)
kcn> repository was probably not available at the time they wrote this:
kcn> "The basis of SVN is a relational database (BerkleyDB). On one
kcn> hand, this settles many problems (for example, concurrent access
kcn> through the file share) and enables new functionalities (for
kcn> example, transactions at operations performance). However, on the
kcn> other hand, data storage now is not transparent, or at least is not
kcn> available for user interference. That is why the utilities for
kcn> 'curing' and 'recovering' of the repository (database) are
kcn> provided."
kcn> Note also that BerkeleyDB is not a "relational database". It's a data
kcn> storage/retrieval mechanism, without relational capabilities.
kcn> Anyway, BerkeleyDB is now one of two options for repository storage.
kcn> I'd also like to point out that the locking/reserved-checkouts
kcn> discussion now under way will soon give us one of the missing features
kcn> PushOk's page talks about the most: CVS's edit/watch functionality.
kcn> -Karl
--
Best regards,
pushok mailto:contact@pushok.com