Greetings, Les Mikesell!
>>> Hmmm ... not sure I understand this concept entirely. I basically use a CVS
>>> tag every time I do a build or a release to "mark" the version of all files
>>> required for that particular build. 99% of the time, this tag is a one time
>>> thing. However, it does happen every-so-often that a build fails b/c
>>> someone forgot to check in a file. So instead of giving it a new build
>>> number once the file is committed, I just retag with the same tag name and
>>> perform the build. Would that concept/workflow cause problems in SVN?
>>
>> This is much less likely to happen with Subversion in general. As I said, each
>> revision slicing the *whole repository* at a certain moment of time, which is
>> supposed to be a complete and functional state. Yep, it's not certainly true,
>> but since it is a complete state, you can always tell that "in this state a
>> building process fails due to this issue, guys - get to work and resolve it".
> A revision number recalls the state that the repository was in when a
> certain transaction completed which doesn't necessarily imply anything
> about the usability at the time.
That's why i'm using the term "supposed". It's not a rule or anything, just a
rude expectation, if you allow me to formulate it this way.
> In CVS you would normally tag the
> repository versions that match your workspace so you could subsequently
> reproduce that workspace state, and you can do that by either adding a
> new tag name or by 'floating' an existing tag to that position. To get
> the same effect in subversion you might have to delete an existing tag,
> then copy your workspace to a tag - which really isn't a very good
> practice since you can easily include things that aren't committed
> elsewhere.
>> At the time you see a revision worth branching to the /release, you run last
>> checks over it and if it is suitable, you "tag" this revision to appropriate
>> place in repository. It does not need a floating tags to continue your work
>> tomorrow, the revision umber already has this function for you. Even if there
>> was commits after the desired revision, you can still refer to the desired
>> revision and finish your work in one way or another.
> But the point is that you need to know this revision number to use it
> for anything. With the floating CVS tags you could embed a known name
> (like RELEASE, RELEASE-1, RELEASE-2) and float the names to appropriate
> revisions to be picked up by subsequent processing. With svn, you have
> to pass revision numbers or tag names around or do something strange
> like deleting tags (which aren't really deleted except for the HEAD
> view) in the repository. That's not necessarily a bad thing, just
> different.
Right all this. It's just one of the caveats you expect from changing your
tools. The new tool does it's work, just in a slightly different way.
As always, there's advantages and disadvantages to this.
In this example situation, I can give the need to adapt your building tools to
the Subversion specific as a disadvantage - it require extra work, but as
advantage, you'll get a tool in the end, that could work with any random
revision in the repository without touching it's structure in any way (if
adaptation was done in the way to allow specifying a certain revision rather
than addressing some constant path in a repository), which could not be easily
achieved with CVS.
--
WBR,
Andrey Repin (anrdaemon_at_freemail.ru) 11.09.2009, <5:06>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393482
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-11 03:15:44 CEST