On 2/25/2006 5:14 PM, Saulius Grazulis wrote:
> On Saturday 25 February 2006 23:56, Duncan Murdoch wrote:
>
>>> I 'svn copy' a "module" to another subdirectory, and play with it
>>> there. It becomes yet another "module".
>> This works ..., but ... In a large project ... will take
>> up a lot of space, download time
>
> You are trying to solve nonexistent problems, instead of discussing the issues
> about labels/tags which I (and other people) have risen.
>
> I don *NOT* have problems with space, download time, etc -- at the moment. And
> when I have them, I *KNOW* how I will solve them. One of the solutions is,
> yes, the one you suggest -- to move subdirs one level deeper. But the moment
> I stick to my current scheme, since it is more relevant for this project.
>
>> ... That's a better way to work.
>
> There is no "better way". There are circumstances where one or another method
> is more appropriate. Having a choice how to implement tags (as labels or as
> copies) would be a welcome freedom and would ease the design of repo layout.
Okay, then write the scripts that would allow that. They are very
simple: you just need to keep a record of revision numbers and symbolic
names somewhere, and be able to do lookups and edits. Subversion
doesn't need to change to accommodate this.
My messages were intended to tell you that what you've described as the
way you work is not such a good idea in the long run, but if you're not
worried about that, then go ahead and write the script.
> There are already many constraints on repo layout (imposed by make system,
> workflow, systems limitations, etc.); one more constraint imposed by a
> version control tool is nice.
>
>> And if you work that way, then creating a tag is simply a cheap copy
>> of the current version of the trunk.
>
> Sure, one can get around the missing labeling mechanism, and I do know how
> (please do not cite 'svn cp trunk tags' command -- I know it, and I have even
> used it). Just it would be nice to have even better tools (no matter how good
> Subversion already is :) -- without the need for workaround.
>
> Again, I do not mean that using 'copies-as-tags' is wrong -- it depends on the
> project, team, you personal tastes after all.
>
> (I am forced to skip a lengthy discussion about repo layout and human errors
> which IMHO is OT here -- for the lack of time).
>
>> ... a) ... b) ... c) ... d)
>>> => e) to mark some state of the project tree which I will want to recall
>>> later, I need to mark a revision number, and only it, for a given repo.
>>>
>>> Tags-as-copies: break d); make c) more difficult; complicate e) since now
>>> a revision number is not enough and we need a path as well. However, a
>>> need for a path is a consequence of an (overcomplicated) repository
>>> layout, which tags-as-copies try to force.
>
> Its a pity that you did not comment on the a-e) issues since they are exactly
> about labels and what functionality I expect from them, unlike discussions
> about how repo/workflow/etc. could/should be organized... Can I assume that
> you agree with all provided arguments?
You can assume whatever you like, but all that you can know for sure is
that I didn't comment on those issues.
>
> Regards,
> Saulius
>
> PS: Please do not Reply/CC to my address when answering to the list -- I get a
> second copy which breaks my filters and "reply-to-the-list" functionality.
> Thank you.
You should be able to set the "Reply-to" header in your message so that
replies automatically go where you want. As far as I know the mailing
list software won't change that.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 26 12:46:00 2006