On 26/09/2014 01:44, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> Joe:
>>> All seems OK to me, except possibly for your parenthetical statement
>>> "one day we really need to move this to trunk".
>>> We can't do this unless we give up the notion that WSJT, MAP65, WSPR,
>>> WSPR-X, and WSJT-X are all part of the same "project". Historically,
>>> the "trunk: of the project is WSJT.
> Bill:
>> Not a problem. Multi project repos usually have
>> project1/{trunk,branches,tags} project2/{trunk,branches,tags} etc..
>>
>> The reason it is important is that most other source control systems
>> have much stronger concepts for branches and tags and moving to them
>> while maintaining all history is normally supported with tools if you
>> have a conventional repo layout.
>>
>> It's not critical or urgent but an example use case is my situation. I
>> use git-svn because it gives me lots of excellent git features while
>> working with svn but because of our repo layout I can't easily have two
>> projects checked out at once ...
> I'm sure you have far more experience with such things than I do. Maybe
> it's not just what you want, but I nearly always have the main branch
> all of our programs -- WSJT, MAP65, WSPR, WSPR-X, and WSJT-X -- checked
> out at once, and the SVN-versioned documentation for them as well.
> Switching between them is no problem at all, I just open a new
> command-line terminal and cd to the right place.
>
> Quite possibly, I'm missing something here -- or don't know about some
> important feature(s) that you want.
It is difficult to explain if you don't have experience of version
control systems where branches and tags are first class objects with
different behaviour and uses, which these days is the case for most
VCSs. svn mimics branch and tag objects with a thin layer of a few
special commands but as you know they are all the same in the repository.
>
> For the record, I have no reason not to like a layout such as
> project1/{trunk,branches,tags} project2/{trunk,branches,tags} etc.,
> except that it's not what we have now -- and as yet I don't appreciate
> why it might be better.
Likewise I have no agenda to force any change and can work with the
current layout without too many issues. I do feel that at some point the
project may have to move away from svn as eventually it will be
considered outdated and obsolete in the face of more convenient code
collaboration tools.
>
> Bill:
>> because it expects everything to reside in
>> the trunk with only branches and tags in their respective locations. For
>> example if I want to build the docs I have to switch my working tree to
>> docs, another branch, which hides the branch I was on 'wsjtx' while I'm
>> there. This is the main reason that I don't edit the docs or contribute
>> to other JT projects as it is so painful to coerce git-svn to bend the
>> standard layout rules.
> If there's a significant reason why it's inconvenient for you to edit
> the docs or contribute to the other JT programs, we should certainly
> address it. But since I don't find such multi-tasking inconvenient at
> all, I need to better understand the problem.
The reason is that git-svn maps svn branches and tags a git branches and
tags which are most definitely not the same as the main line. The
inconvenience comes from the fact that switching to a branch hides the
previous contents of the workspace so for example if I switch to the
docs branch then my workspace ONLY contains the doc branch and if I
switch back the docs are hidden and the wsjtx files reappear. This makes
perfect sense if the branch were a real branch with a common ancestor
but is very inconvenient if I want to refer to both at once.
It is my choice to use git-svn so I have to live with the consequences
and I won't go into the benefits that gives me other than to say that
they far outweigh the small inconvenience of navigating a non-standard
repository layout. It certainly doesn't restrict my ability to
contribute to at least one project at a time.
>
> -- 73, Joe, K1JT
73
Bill
G4WJS.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
